Deployment
What actually has to be true for a build to become a running, reachable production service.
1 hrOverview
Deployment is the process of taking a built artifact — a Docker image, a compiled JAR, a Next.js build — and making it a running, reachable service in production, with a domain, TLS, and the correct environment configuration.
Why it matters
Code that only runs on your laptop delivers zero value. Understanding deployment is what separates "I built a feature" from "I shipped a feature a user can actually reach."
How backend developers use it
A typical split for a Java/Next.js stack: the Spring Boot API and its PostgreSQL database deploy together on a platform like Railway (which handles the database, environment variables, and HTTPS for you), while the Next.js frontend deploys separately on Vercel and calls the API's public URL — two independently deployable pieces connected by one environment variable (the API's base URL).
Common mistakes
Warning
Deploying a debug build with verbose logging and stack traces exposed to the client — production builds should never leak internals in error responses.
Warning
No health check endpoint, so the platform can't tell the difference between "starting up" and "crashed" and routes traffic to a dead instance.
Warning
CORS configured for localhost only, so the deployed frontend can't call the deployed API until someone remembers to update the allowed origins.
Warning
Treating the first successful deploy as "done" with no plan for what happens when the next deploy breaks something — always know how to roll back before you need to.
Example commands
Deploy the current directory to Vercel
vercel --prod
Deploy via the Railway CLI
railway up
Resources
Retrieval check
Before you continue
- Explain what this tool or practice changes in the delivery lifecycle.
- Name one common failure it helps you diagnose or prevent.
- Repeat one example command from memory, then verify it.