Railway simplifies cloud deployments with automatic build detection via Nixpacks and a simple service model. These exercises cover the key concepts for deploying and connecting services on Railway.
0 / 5 completed
1 / 5
At standup, a colleague asks what Nixpacks is in the context of Railway deployments. What is the correct answer?
Nixpacks is Railway's open-source build system. It inspects your repository, detects the language and package manager, generates a build plan using Nix packages, and produces a container image — all without a Dockerfile. It supports Node.js, Python, Ruby, Go, Rust, and more. You can override detection or add custom build steps via a nixpacks.toml file.
2 / 5
During a PR review, a teammate asks what Railway services are. Which answer is correct?
In Railway, a service is the fundamental deployment unit. A project contains one or more services, each of which can be a GitHub repository (built with Nixpacks or a Dockerfile), a Docker image, or a managed database (PostgreSQL, Redis, MySQL, MongoDB). Each service has its own environment variables, domains, networking, and scaling configuration. Services within the same project can communicate over Railway's private network.
3 / 5
In a design review, the team discusses ephemeral storage on Railway. What does this mean for stateful workloads?
Railway containers use ephemeral storage by default: the container filesystem is rebuilt on each deploy or restart, and any locally written data is lost. This is standard for stateless container deployments. For stateful workloads (file uploads, SQLite databases, etc.) you must use Railway's managed database services (Postgres, Redis) or an external storage provider like S3, since Railway does not currently offer persistent volume mounts for custom services.
4 / 5
An incident report shows two Railway services in the same project unable to reach each other. A senior engineer asks how private networking works on Railway. What is correct?
Railway provides private networking within a project: each service gets a private hostname in the form service-name.railway.internal (and a corresponding RAILWAY_PRIVATE_DOMAIN environment variable). Traffic between services on this network stays within Railway's infrastructure and does not traverse the public internet. You must use the private hostname and the service's internal port — not the public domain — for private communication.
5 / 5
During a code review, a senior engineer asks what the deploy config options (start command, healthcheck, restart policy) do on Railway. What is accurate?
Railway's deploy config gives you fine control over runtime behaviour. The start command overrides the container's default CMD. The healthcheck (HTTP path + timeout) lets Railway verify the service started correctly before routing traffic — a failed healthcheck rolls back the deploy. The restart policy determines what Railway does if the process exits (always restart, restart on failure, or never). Together these settings make deployments more reliable and observable.