Railway Deployment
If you already use Railway for Right Events, the cleanest setup is to deploy the docs as a separate Railway service from the same repository.
Recommended layout
- Main web app: one Railway service for the Next.js application
- Docs app: one Railway service for
docs-site/
This keeps deployments independent and avoids mixing the Docusaurus build with the production app build.
Best option: set the service root directory to docs-site/
In Railway:
- Create a new service from this repository.
- Set the root directory to
docs-site/. - Use Node 20+.
Recommended commands:
- Build command:
pnpm install && pnpm build - Start command:
pnpm serve --host 0.0.0.0 --port $PORT
Fallback option: keep the repo root as service root
If you do not want to use Railway's root-directory setting, use these commands instead:
- Build command:
pnpm --dir docs-site install && pnpm --dir docs-site build - Start command:
pnpm --dir docs-site serve --host 0.0.0.0 --port $PORT
Suggested domains
docs.rightevents.cofor production docsdocs-staging.rightevents.cofor preview or staging docs
Environment variables for the docs service
The docs app is static-first and needs very little configuration. In most cases, no secrets are required.
Useful optional values:
PORT: Railway injects this automaticallyNODE_ENV=production
Deployment workflow
The docs site ships from files under docs-site/. A normal deployment cycle is:
- Update docs content
- Merge to the deployment branch
- Railway rebuilds the docs service
- Attach or update the custom docs domain
Local parity
You can validate the exact service behavior locally:
pnpm docs:install
pnpm docs:build
PORT=3001 pnpm docs:serve
Interaction with the main app
The docs deployment is operationally separate from:
- the Next.js runtime
- Convex deployment
- the Python backend
- Railway release ingestion in
convex/http.ts
That separation is intentional. Docs should be low-risk to ship and easy to roll back without touching the main product.