Deploy Casdoor

Deploy and Host Casdoor on Railway

Casdoor is an open-source, UI-first identity and access management platform from the Casbin team — a full single sign-on server speaking OAuth 2.0, OIDC, SAML, CAS, LDAP, SCIM, WebAuthn, TOTP and RADIUS, driven by an admin console rather than the XML and realm files older identity servers expect. Built on Casbin, it also carries a real authorization engine, so RBAC, ABAC and ACL policies live beside the accounts they apply to. Teams reach for it when several internal apps need one login, when a SaaS product needs multi-tenant sign-up without renting an identity vendor, and when LLM tools and MCP servers need an auth server in front of them.

Self-host Casdoor on Railway and this template gives you the production shape, not the quickstart one. Three services are wired together: the Casdoor server, serving the JSON API and bundled React admin UI on one public domain; a PostgreSQL database holding every object Casdoor owns — users, organizations, applications, signing certificates, tokens and Casbin rules; and Redis holding login sessions. A volume is attached for uploads. Nothing is left to fill in: the first administrator password is generated at deploy time, the JWT signing certificate is minted on first boot, and self-service sign-up is closed by default.

Getting Started with Casdoor on Railway

Open the generated public URL and you land on the Casdoor sign-in page. Log in as admin with the password held in CASDOOR_ADMIN_PASSWORD on the Casdoor service — the documented default of admin / 123 is deliberately never created here — and change it from the avatar menu. Next, create an organization under User Management → Organizations; that is the tenant your end users belong to, since the built-in organization is reserved for Casdoor's own administrators and refuses ordinary accounts. Then open Identity → Applications, add an application for the service you want to protect, set its redirect URL, and copy its Client ID and Client Secret from the OIDC/OAuth tab. Point your OIDC library at https://your-domain.up.railway.app/.well-known/openid-configuration and it finds every endpoint. To confirm real tokens are being issued:

curl -s -X POST https://your-domain.up.railway.app/api/login/oauth/access_token \
  -d grant_type=client_credentials \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET

The response carries an RS256 JWT that verifies against the keys at /.well-known/jwks, with an iss matching your public domain.

About Hosting Casdoor

Casdoor replaces the half-finished login code most projects accumulate: instead of every application building its own password reset, MFA prompt and social login, they delegate to one server that owns the accounts. Self-host it when user records cannot leave your infrastructure, when per-user identity pricing stops making sense, or when authorization rules belong next to the directory.

Key features:

• OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP and SCIM from a single server
• WebAuthn, TOTP, email and SMS multi-factor authentication
• Dozens of social and enterprise identity providers, from Google Workspace and Azure AD to GitHub and WeChat
• Casbin RBAC, ABAC and ACL permission models with a policy editor
• Multi-tenant organizations, groups, roles and invitations
• SDKs for Go, Java, Python, Node.js, PHP and .NET

The architecture is deliberately plain. The Casdoor service is a single Go binary that also serves the compiled React console, so there is no separate frontend to route, and it migrates its own schema on boot. Redis is not decoration — without it Casdoor writes sessions to the container filesystem, so everyone is signed out on every redeploy and the service cannot scale past one replica. The volume backs Casdoor's local file storage provider.

Why Deploy Casdoor on Railway

Railway removes the setup work that surrounds an identity server.

• PostgreSQL and Redis are provisioned and wired up for you
• HTTPS and a public domain are issued automatically, so the OIDC issuer is valid at once
• Secrets are generated per deployment; no shipped default password
• Database, cache and volume all persist across redeploys
• Scaling up or out without touching the configuration

Common Use Cases

• One sign-on for a suite of internal tools — dashboards, wikis, CI, admin panels — each speaking OIDC
• The auth server for a multi-tenant SaaS product, organizations mapping to customers
• A central directory bridging modern and legacy apps via its LDAP and RADIUS listeners
• An identity and permission layer in front of LLM gateways and internal AI tooling

Dependencies for Casdoor

• Casdoor — built from the casbin/casdoor image; API and admin UI on port 8000
• PostgreSQL — Railway managed Postgres 18; stores every Casdoor object
• Redis — Railway managed Redis 8.2; session and device-auth store
• Volume — at /files, for uploads

Environment Variables Reference

Deployment Dependencies

• Source image: casbin/casdoor on Docker Hub
• Source repository: github.com/casdoor/casdoor
• Documentation: casdoor.org/docs

Hardware Requirements for Self-Hosting Casdoor

Casdoor is light. First boot is the expensive moment — it generates a 4096-bit RSA signing certificate and creates the schema — after which a small deployment idles in a few hundred MB.

Self-Hosting Casdoor with Docker

Casdoor reads conf/app.conf, and every key in it is overridable by an environment variable of the same name. One container against an existing PostgreSQL database:

docker run -d --name casdoor -p 8000:8000 \
  -e driverName=postgres \
  -e "dataSourceName=postgresql://user:pass@db-host:5432/casdoor?sslmode=disable" \
  -e httpport=8000 \
  -e 'logConfig={"adapter":"console"}' \
  casbin/casdoor:latest

To build from source, clone the repository, edit conf/app.conf, and run the server and frontend together:

git clone https://github.com/casdoor/casdoor
cd casdoor && go run main.go
cd web && yarn install && yarn start

Either way you supply the database and terminate TLS in front. Leave the signing certificate alone — rotating it invalidates every token already issued.

How Much Does Casdoor Cost to Self-Host?

Casdoor is free and open source under the Apache 2.0 licence — no user caps, no paid feature tiers, no licence key. Every protocol, identity provider and the whole permission engine are in the public build. The Casbin team sells a managed Casdoor Identity Cloud from around $9 per month if you would rather not run it. On Railway you pay only for the resources the three services use.

FAQ

What is Casdoor? An open-source identity and access management platform — a single sign-on server for your applications, supporting OAuth 2.0, OIDC, SAML, CAS, LDAP, SCIM and RADIUS, with a Casbin authorization engine for RBAC and ABAC policies.

What does this Railway template deploy? The Casdoor server on a public HTTPS domain, a PostgreSQL database and a Redis instance, plus a volume for uploaded files. Everything is connected and the first administrator account is created for you.

Why does the template include PostgreSQL and Redis? PostgreSQL is where Casdoor keeps every object it owns. Redis holds login sessions; without it Casdoor falls back to session files inside the container, lost on every redeploy and unshareable between replicas.

What are the default login credentials for self-hosted Casdoor? Upstream Casdoor creates admin with the password 123. This template does not — it generates one at deploy time and seeds the account with that. Read CASDOOR_ADMIN_PASSWORD on the Casdoor service, then change it after your first login.

How do I connect my application to self-hosted Casdoor with OIDC? Create an application in the admin console, add your redirect URL, and copy its Client ID and Client Secret. Then point your OIDC client at https://your-domain/.well-known/openid-configuration, which advertises the authorization, token, userinfo and JWKS endpoints for you.

Does Casdoor work with a custom domain? Yes. Leave origin empty, attach your domain in Railway, and tokens are issued under the new hostname — Casdoor derives the issuer from the incoming request.