Render and Railway are the fastest ways to get Omnigent running in the cloud — no local tooling required, no database to provision separately, and HTTPS is handled automatically. Both platforms wire a managed Postgres database to the service as part of the deploy, and both default to built-inDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/omnigent-ai/omnigent/llms.txt
Use this file to discover all available pages before exploring further.
accounts auth so a fresh deploy is multi-user with no external identity provider. Render is the smoother one-click path today; Railway requires a few manual wiring steps (a full template is tracked as a follow-up).
Both Render and Railway auto-provision a managed Postgres database as part of the deploy.
OMNIGENT_AUTH_ENABLED defaults to 1, so multi-user auth is on from the first boot.Render
Render provisions the app, a managed Postgres database, and a persistent artifact disk in a single step from therender.yaml blueprint in the repo.
Click Deploy to Render
- omnigent (Starter web service) — pulls
ghcr.io/omnigent-ai/omnigent-server:latest; served onhttps://omnigent-<hash>.onrender.com - omnigent-db (
basic-256mbmanaged Postgres) —DATABASE_URLinjected automatically - artifact-data (10 GB persistent disk) — mounted at
/data/artifactsso agent bundles survive redeploys
Get the admin password from the service logs
Open the service in the Render dashboard → Logs and look for the first-boot block:The password is also written to
/data/admin-credentials on the persistent disk (printed once; later boots do not reprint it).Sign in and invite teammates
Open your
https://omnigent-<hash>.onrender.com URL and log in as the admin. Go to your username → Members → Invite member to share single-use invite links with teammates.basic-256mb managed Postgres = ~$13/month for a lightly loaded instance. The web service requires a paid (Starter+) tier because of the persistent artifact disk; Render’s free Postgres plans expire.
Custom domain: in the Render dashboard, open the service → Settings → Custom Domains → Add Custom Domain. Point your DNS CNAME at the Render-assigned address; Render provisions a Let’s Encrypt cert automatically.
Railway
Railway pulls the pre-built image, runs it alongside a managed Postgres plugin, and serves it over HTTPS on*.up.railway.app.
Railway is not yet a true one-click deploy. Unlike Render’s fully declarative
render.yaml, a Railway deploy requires a few manual wiring steps (see below). Render is the smoother path today.Create a new Railway project from GitHub
Go to the Railway dashboard → New Project → Deploy from GitHub repo → select this repo. Railway reads
railway.toml and pulls the image. Add a Postgres plugin to the project from the project settings.Confirm DATABASE_URL is wired
Railway links the Postgres plugin’s
DATABASE_URL into the app service as a reference variable (${{Postgres.DATABASE_URL}}). This is largely automatic when you add the plugin. If the first deploy errors with DATABASE_URL is required, the reference value had not yet propagated — redeploy and it resolves.Get the admin password from Deploy logs
Open the service → Deploy logs and look for:The password is also written to
/data/admin-credentials. The cookie secret and OMNIGENT_ACCOUNTS_BASE_URL are auto-detected from Railway’s environment variables — no manual setting needed.Sign in and invite teammates
Open your Railway-assigned URL, log in as
admin, and invite teammates from Members in the web UI.If the generated domain returns “Application failed to respond,” Railway’s port auto-detect may have picked the wrong port. Open Settings → Networking and set the domain’s target port to the PORT value Railway injected (shown in the boot log as Uvicorn running on …:<port>).After deploying
Once the server is live on either platform, your team can:- Sign in at the HTTPS URL with the admin credentials from the first-boot logs
- Invite teammates via Members → Invite member in the web UI (single-use invite links)
- Connect their laptops with
omnigent login <url>thenomnigent host <url>
Switching to OIDC auth
Both platforms default to built-inaccounts auth. To switch to SSO with GitHub, Google, Okta, or any OIDC provider, add the OMNIGENT_OIDC_* environment variables in the platform’s environment/variables dashboard and redeploy.
For Render, open the service → Environment. For Railway, open the service → Variables. The key variables to add:
| Variable | Value |
|---|---|
OMNIGENT_AUTH_PROVIDER | oidc |
OMNIGENT_OIDC_ISSUER | Your IdP’s base URL (e.g. https://github.com, https://accounts.google.com) |
OMNIGENT_OIDC_CLIENT_ID | OAuth client ID from your IdP |
OMNIGENT_OIDC_CLIENT_SECRET | OAuth client secret from your IdP |
OMNIGENT_OIDC_REDIRECT_URI | https://<your-domain>/auth/callback |
OMNIGENT_OIDC_COOKIE_SECRET | Output of openssl rand -hex 32 |
OMNIGENT_OIDC_ALLOWED_DOMAINS to your company domain — without it, any Google account can log in when the OAuth consent screen is “External.”
For the complete OIDC walkthrough and header-proxy mode, see the Auth page.