Deploy and Host Unla on Railway

Unla is a lightweight MCP gateway written in Go. It turns existing REST APIs and MCP servers into MCP servers through configuration alone, with no code changes, and ships a web admin UI for managing tenants, users, MCP server configs, OpenAPI imports and config versions.

About Hosting Unla

This template runs the official all-in-one Unla image as a single service:

Unla (ghcr.io/amoylab/unla/allinone): nginx on port 80 serves the admin UI and proxies /api to the API server and /gateway to the MCP gateway. A bundled mock backend runs internally only.
Volume at /app/data holding the SQLite database (users, tenants, MCP server configs and their version history).
Generated secrets: the super admin password and the JWT signing key are generated per deployment.
Auth: the admin UI and the whole /api management API require login. No default password is shipped.

After deploy:

Open the service's Variables tab and copy SUPER_ADMIN_PASSWORD.
Open https://YOUR-RAILWAY-DOMAIN and log in as admin with that password.
Change the password in the UI if you like. The variable only seeds the account on first boot, so later edits to it have no effect.
Add MCP servers or import an OpenAPI spec. Gateway endpoints are served at https://YOUR-RAILWAY-DOMAIN/gateway/....
Optional: to enable Google or GitHub login, create an OAuth app with the redirect URI shown in GOOGLE_OAUTH_REDIRECT_URI / GITHUB_OAUTH_REDIRECT_URI and add GOOGLE_OAUTH_CLIENT_ID + GOOGLE_OAUTH_CLIENT_SECRET (or the GITHUB_ equivalents) as variables.

Common Use Cases

Expose an internal or third-party REST API to AI agents as MCP tools without writing an MCP server
Put several MCP servers behind one gateway URL with per-tenant prefixes
Version and roll back MCP tool configurations from a web UI
Share one hosted MCP endpoint across a team instead of running local stdio servers

Dependencies for Unla Hosting

Source: AmoyLab/Unla (MIT license)
Image: ghcr.io/amoylab/unla/allinone:v0.10.0
No API keys are required. LLM and OAuth settings are optional.

Deployment Dependencies

Implementation Details

All configuration is passed as environment variables; the image already contains config files that read them, so no files need to be mounted.
PORT is set to 5234 because the API server honours Railway's PORT; nginx stays on port 80, which is the port the public domain targets.
SQLite on a Railway volume keeps it to a single service. The API server and gateway share one database file at /app/data/unla.db.
The healthcheck uses /api/auth/oauth/providers, a public API server route that returns 200 once the API server is up.
VITE_GATEWAY_SERVICE_BASE_URL points the UI's copyable gateway URLs at https://YOUR-RAILWAY-DOMAIN/gateway, because only port 80 is publicly exposed.

Why Deploy Unla 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 Unla on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.