HOW TO SECURE RAILWAY - SECURITY GUIDE | VIBEEVAL

Railway Security Context

Railway is a container PaaS — push from GitHub, get a service. The platform handles TLS, basic networking, and OS patching. Your residual surface lives in: variables (the secrets store), Private Networking (which you have to opt into), the Docker / Nixpacks build process (which can leak secrets via build args), and the per-service public domain (which is reachable from the internet by default unless you make the service private).

Security Checklist

1. Store secrets in Railway variables, never in code

Project → Variables: add per-environment values. Reference in code as process.env.MY_VAR. Variables marked as “Sealed” are encrypted and not displayed in the UI after creation. Use Sealed for production secrets you don’t need to read back.

2. Enable Private Networking between services

Each service in a project gets a <service>.railway.internal hostname when Private Networking is on. Configure your backend services to communicate over .railway.internal URLs — never via the public *.up.railway.app URLs. Public URLs are reachable from the internet; private hostnames are not.

3. Configure database security

For Railway Postgres / MySQL / Redis / Mongo: use the Internal URL (*.railway.internal) wherever possible, the Public URL only when required. Confirm the connection string requires TLS (?sslmode=require for Postgres). Rotate the password by re-deploying the database service.

4. Implement application-level authentication

Railway doesn’t add auth — your app does. For every protected route: check the session in the first three lines of the handler. Test by hitting protected routes from incognito; expect 401.

5. Audit container security

Review the Dockerfile (or nixpacks.toml): non-root user (USER nonroot), no secrets baked into layers (use ARG only for non-secrets — for secrets, use BuildKit --mount=type=secret), pinned base image versions (digests, not :latest), EXPOSE only the ports you serve.

6. Configure health checks

In service settings → Health Check Path: set to /health. Failed health checks trigger restarts; configure the restart policy under Settings → Restart Policy (on_failure is usually correct).

7. Verify HTTPS

Railway provisions TLS automatically. For custom domains, confirm cert provisioning completed: Service → Settings → Domains. Test by hitting http://yourdomain.com and confirming the redirect.

8. Configure team permissions

Project → Members: review quarterly. Owner / Member roles. Members can deploy and read variables — keep the list small. Remove ex-team members same-day; rotate sensitive variables after departure.

9. Audit build logs

Service → Deployments → [deploy] → Build Logs: search for leaked secrets. A common bug ships when a build step RUN echo $SECRET_VAR for “debugging,” dumping the value into logs.

10. Configure resource limits

Service → Settings → Resources: set explicit CPU / memory / replica limits. Railway’s “Pay as you go” model means unbounded resource growth = unbounded bill. An attacker triggering expensive operations is a financial DoS without limits.

11. Enable audit logging

Project → Settings → Audit Log: track deploys, variable changes, member additions. Useful for incident response.

12. Review network access

For services with the public *.up.railway.app domain: confirm you actually want them public. Toggle off Networking → Public Networking for services that should be private. Only the public-facing ones (the user-visible web app) should have public domains.

13. Set up backups

For databases: Railway’s automated backups depend on the database type and plan tier. Confirm retention matches your requirement. For services with persistent volumes, schedule volume snapshots as a cron service.

14. Audit cron jobs and scheduled services

Railway supports cron triggers. For each scheduled service: review what it does and what variables it has access to. Cron services run without a user context — they should be system-level operations.

15. Configure monitoring

Railway’s built-in metrics show CPU / memory / network. For richer alerting, integrate Datadog / Better Stack / your platform. Alert on: error-rate spikes, sustained high CPU (could be cryptojacking), unusual outbound traffic (data exfiltration).

16. Run a security scan

The full VibeEval scan probes your deployed Railway app for missing auth, BOLA, and webhook trust — independent of where it’s hosted.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

PostgreSQL Guide

Secure your Railway Postgres deployment.

Automate Your Security Checks

VibeEval scans applications hosted on Railway for missing auth, BOLA, exposed admin endpoints, and bundle-side leaks.