---
title: "Deploy SILO"
description: "Self-host S3 storage — SILO, a maintained MinIO fork with full console"
category: "Storage"
url: https://railway.com/deploy/silo
---

# Deploy SILO

Self-host S3 storage — SILO, a maintained MinIO fork with full console

**[Deploy SILO on Railway](https://railway.com/template/silo)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/silo/manifest.json

- **Creator:** SB
- **Category:** Storage

## Template content

### SILO https://silo.pgsty.com/img/silo.svg

- **Image:** pgsty/silo:RELEASE.2026-09-16T00-00-00Z-distroless

## Documentation

# Deploy and Host SILO on Railway

SILO is an S3-compatible object storage server maintained by Pigsty — a community fork of MinIO, created because the upstream repository was archived in April 2026 with no further releases, Helm charts or image updates. It keeps the S3 API, `MINIO_*` variables, metrics, headers and on-disk format unchanged, and keeps the admin console upstream had removed. This template runs it with a volume, generated root credentials, and the proxy setting that makes its access policies mean what you think.

## What This Template Deploys

| Service | Purpose |
| --- | --- |
| `silo` | S3 API on `9000`, admin console on `9001`. Objects, buckets, IAM, lifecycle rules. |
| Volume | Mounted at `/data` — every object, bucket and policy you store. |

One service, one volume, no database. Note the two ports: Railway gives a service one public HTTP domain, so decide deliberately which of the S3 endpoint and the console is reachable from outside, and keep the other private.

## About Hosting

SILO's appeal is that nothing about it is new — the protocol, variables and data format are MinIO's. The things that *have* changed are the ones that bite, because a drop-in replacement is exactly what nobody re-reads release notes for.

**Policies that worked on MinIO can fail here.** SILO tightened resource matching: a `bucket/*` grant no longer authorises twelve sensitive bucket-level writes on Allow statements, which now need `arn:aws:s3:::bucket` alongside the object pattern. Migrating existing IAM policies, expect some to stop working and fix them properly. `MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on` restores the old behaviour as a migration control, not a setting to leave on.

**Behind Railway's proxy, every request appears to come from one address.** `aws:SourceIp` conditions and audit attribution read the client address, and behind an edge proxy that is the proxy. `MINIO_API_TRUSTED_PROXIES` makes the boundary explicit and enforceable; unset, it preserves permissive behaviour and your IP conditions evaluate against the wrong thing.

**The binary is `silo` and the client is `mcli`.** The fork renames delivery surfaces while preserving the protocol, and deliberately installs no `minio` alias. Scripts, units and runbooks invoking `minio` or `mc` need updating, even though nothing about your data or API calls does.

**One node means no erasure coding.** A single-node deployment has no redundancy — the volume is the only copy of every object. Fine for a backup target, a development bucket, or assets you can regenerate. Not a durability story for anything irreplaceable, and S3 compatibility does not change that.

**Pin a release, and do not build from main.** The project ships dated server releases while the main branch carries unreleased security, storage and console changes. Pin a published release tag, read its notes before bumping, and treat upgrades as something you schedule.

**The console is an admin surface, not a file browser.** It manages IAM, lifecycle, replication and tiering, which makes the root password the boundary around your whole storage layer. Generate it, never reuse it, and think before giving the console a public domain.

Typical cost: **~$8–20/month** for one small service at $10/GB/month RAM and $20/vCPU/month, plus $0.15/GB/month for whatever you store. SILO is AGPL-3.0 and free.

## How It Compares

| | SILO | MinIO upstream | Garage | AWS S3 |
| --- | --- | --- | --- | --- |
| Maintained | Yes, dated releases | Repository archived Apr 2026 | Yes | Yes |
| Admin console | Included | Removed upstream | Minimal | AWS console |
| Drop-in for MinIO clients | Yes, by design | — | Partial | No |

The honest edge: starting fresh with modest needs, Garage is lighter and was designed for small self-hosted deployments rather than inherited from a larger system. Real S3 wins outright on durability, and nothing self-hosted on one node competes there. SILO's case is narrow and strong: you already run MinIO, or depend on something that speaks to it, and upstream stopped. It keeps your clients, variables and data format working under a project still shipping releases.

## Deploy in Under 5 Minutes

1. Click **Deploy** and pick a workspace. SILO comes up with a volume at `/data` and a generated root password.
2. Decide which port gets the public domain — the S3 API on `9000` for external clients, or the console on `9001` for administration. Keep the other private.
3. Sign in to the console with `MINIO_ROOT_USER` and the generated password from the service variables.
4. Create a bucket and an access key scoped to it. Do not hand the root credentials to an application.
5. Set `MINIO_API_TRUSTED_PROXIES` before writing any policy that depends on source IP.

> Verify before you rely on it: upload an object, redeploy the service, then list the bucket. Still there means the volume is mounted at `/data`. Empty means stop and fix the mount before storing anything real.

## Common Use Cases

- **A maintained replacement for archived MinIO** — keep existing clients, SDK calls and `MINIO_*` config working without rewriting anything.
- **S3 storage beside your app** — uploads, exports and attachments over private networking, with no egress to a cloud provider.
- **PostgreSQL backup target** — Pigsty uses it as a backup repository, which is the workload it is maintained for.

## Configuration

| Variable | Required | Description |
| --- | --- | --- |
| `MINIO_ROOT_USER` | Pre-set | Console and admin login. Not for application use. |
| `MINIO_ROOT_PASSWORD` | Generated | Root credential for the whole storage layer. Never reuse or share it. |
| `MINIO_API_TRUSTED_PROXIES` | Recommended | Makes `aws:SourceIp` conditions and audit attribution meaningful behind Railway's edge. |
| `MINIO_SERVER_URL` | Optional | Public S3 endpoint, when presigned URLs must resolve externally. |
| Storage volume | Pre-set | Mounted at `/data`. Every object lives here. |

> **Create scoped access keys for applications.** The root credential administers IAM, lifecycle and replication — an application that only needs to write to one bucket should never hold it.

> **Do not leave `MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH` enabled.** It exists to get migrated policies working while you correct them, and it restores a resource-matching behaviour that was tightened for a reason.

## Dependencies for SILO Hosting

- **Railway account** — ~$8–20/month for the service, plus $0.15/GB/month for stored objects.
- **Bundled services** — none. SILO needs no database and no companion service.
- **Volume** — required at `/data`. It is the only copy of your objects on a single-node deployment.
- **Optional** — `mcli`, the fork's client, for scripting and bucket administration from outside the console.

### Deployment Dependencies

- [SILO on GitHub](https://github.com/pgsty/silo)
- [SILO documentation](https://silo.pgsty.com)
- [SILO Console](https://github.com/pgsty/silo-console)
- [Railway volumes](https://docs.railway.com/volumes)

### Implementation Details

SILO runs the official distroless image pinned to a dated release rather than a floating tag, started as `silo server /data --console-address :9001`. The S3 API answers on `9000`, the console on `9001`, with the volume mounted at `/data` — the path the server command names, so a mount anywhere else gives a healthy-looking service writing into a container layer the next deploy discards.

Compatibility is the fork's organising principle, and it is worth knowing how far it extends. The S3 API, `MINIO_*` variables, `minio_*` metrics, `x-minio-*` headers, `/minio/*` reserved routes and the on-disk format including `.minio.sys` are preserved and guarded by a CI compatibility check. What changes is delivery: executable, package, service unit, Helm chart and image carry the new name, and no `minio` alias is installed. Your SDK calls and bucket data move across untouched; your scripts do not.

Behaviour changes arrive through release notes rather than the protocol, and the IAM resource-matching change is the one to read before migrating. Policies written against MinIO's looser matching may grant less than they did, surfacing as access-denied errors on operations that previously worked rather than anything resembling an upgrade problem. Pin your version, read the notes for each bump, and back up the volume first — a single node has no second copy.

## Frequently Asked Questions

**Why use a fork instead of MinIO?** The upstream repository was archived in April 2026, ending releases, Helm chart updates and image maintenance. SILO continues the open-source line with dated releases.

**Will my existing MinIO clients work?** Yes. The S3 API, variables, metrics, headers and storage format are preserved deliberately and checked in CI. Your SDK code needs no change.

**What breaks when migrating?** Command names — the binary is `silo` and the client is `mcli`, with no `minio` alias — and IAM policies that relied on looser bucket resource matching.

**Can I expose both the API and the console publicly?** Not from one service; Railway gives a service one public HTTP domain. Publish one and keep the other on the private network.

**Is one node durable enough?** No erasure coding means the volume is the only copy. Use it for backups, assets and development data, and keep a copy elsewhere for anything irreplaceable.

## Why Deploy SILO on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying SILO on Railway you get S3-compatible storage configured for the things its compatibility promise does not cover — a pinned release rather than a moving tag, the volume on the path the server actually writes to, trusted-proxy handling so IP-based policies mean something, and root credentials generated rather than defaulted.

## Similar templates

- [RustFS | (Just Updated) S3 Object Store, Public URL and Keys Set](https://railway.com/deploy/rustfs-or-just-updated-s3-object-store-p) — S3-compatible object store, keys and public URL preset, volume kept
- [TimescaleDB](https://railway.com/deploy/timescaledb-railway-template) — A PostgreSQL-based time-series database for analytics on Railway.
- [Garage S3 Storage](https://railway.com/deploy/garage-s3-storage) — Ultra-light S3 server: fast, open-source, plug-and-play.

Open this page in a browser: https://railway.com/deploy/silo