Deploy and Host SlashDocs on Railway

slashdocs is an open-source server from Razorpay that gives AI agents a place to publish self-contained HTML documents that humans can review. Agents push documents through the API, CLI, or remote MCP server; people read them in a web UI, leave comments anchored to text, and track versions.

About Hosting SlashDocs

slashdocs ships as one Go binary with the React UI embedded. It needs Postgres for metadata, an S3-compatible bucket for the uploaded HTML, and an OpenID Connect identity provider for human sign-in. This template runs the pinned image razorpay/slashdocs:0.1.1 next to a Railway Postgres service, a versitygw S3 service with a volume, and a Dex identity provider with a single static admin user, so you can sign in minutes after deploying without creating a Google or Okta app first. A small Caddy service provides the second hostname that slashdocs requires for sandboxed document rendering. All five services talk over Railway's private network and every secret is generated on deploy.

Common Use Cases

Agent reports: coding or research agents publish HTML reports that teammates review with comments
Versioned specs: each push creates a new immutable version with a diffable history
Internal documentation: agents keep runbooks and dashboards fresh, humans approve changes
MCP endpoint: connect Claude, Cursor or other MCP clients to /mcp and let them publish directly
Private knowledge base: documents are shared per user, per link, or org-wide

Dependencies for SlashDocs Hosting

PostgreSQL: included, migrations run on boot
S3-compatible storage: included (versitygw with a Railway volume), or point BLOB_* at AWS S3, R2 or MinIO
OIDC provider: included (Dex static user), replaceable with Google, Okta, Entra ID or Keycloak
Second hostname for renders: included (Render service), or a custom domain on SlashDocs

Deployment Dependencies

Implementation Details

The SlashDocs service listens on PORT=8080 and reports readiness on /readyz once Postgres and the bucket answer. Dex renders its config through gomplate at boot, bcrypt-hashing the generated DEX_ADMIN_PASSWORD and registering the slashdocs callback URL. The Render service runs caddy reverse-proxy to SlashDocs while keeping the original Host header, which is how slashdocs tells a render request from an app request.

SLASHDOCS_APP_ORIGIN=https://${{RAILWAY_PUBLIC_DOMAIN}}
SLASHDOCS_RENDER_ORIGIN=https://${{Render.RAILWAY_PUBLIC_DOMAIN}}
SLASHDOCS_OIDC_ISSUER_URL=https://${{Dex.RAILWAY_PUBLIC_DOMAIN}}/dex
SLASHDOCS_OIDC_INTERNAL_ISSUER_URL=http://${{Dex.RAILWAY_PRIVATE_DOMAIN}}:5556/dex
DATABASE_URL=${{Postgres.DATABASE_PRIVATE_URL}}
BLOB_ENDPOINT=http://${{Blob.RAILWAY_PRIVATE_DOMAIN}}:9000

First steps after deploy: open the SlashDocs domain, click Continue with Dex, and sign in with DEX_ADMIN_EMAIL (default admin@example.com, editable) and the generated DEX_ADMIN_PASSWORD from the Dex service variables. Create a service account and key in the UI, then publish with curl -F file=@report.html -F title=... https://your-slashdocs-domain/v1/documents or install the CLI from /install.sh. To move to your company SSO later, set the provider variables on SlashDocs and delete the Dex service.

Why Deploy SlashDocs 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 SlashDocs on Railway, you get the full upstream stack (app, Postgres, S3 storage, identity provider, render origin) wired together with generated secrets, health checks, managed SSL, and private networking, ready for agents to publish to on day one.