Deployment Basics: How a Website Goes from Code to Live
Many people just learning to build websites wonder: the code runs perfectly on my own computer, so how do I let everyone in the world access it? That process is called deployment. Think of it like opening a food-delivery restaurant: you (the developer) cook the food, and deployment is carrying the finished dishes to the storefront, arranging them on the counter, and opening the doors so customers can order and pick up. The storefront customers see is the website running on your server. This guide breaks down that "code to live" chain and compares five common deployment methods.
What deployment is
In one sentence: deployment is the process of moving code from a development environment to a long-running server environment and making it serve traffic. The development environment is the "kitchen" (your local machine); the production environment is the "storefront" (the server). Deployment is not just "upload the files" — it also covers installing dependencies, configuring the database, setting up the domain and HTTPS, starting the service, and checking that everything works. To understand the relationship between servers and websites first, see cloud server basics.
The complete chain from code to live
A complete release chain usually has five stages, and a mistake at any point can sink the launch:
- Develop: Write and debug code locally, recording every change with Git. For team collaboration, use branches for features and fixes, as covered in the Git deployment workflow.
- Build: Turn source code into runnable artifacts — minify JS/CSS, bundle frontend assets, compile the backend, and generate static files. This step must be repeatable both locally and on the server, with consistent results.
- Test: Run everything in a "staging environment": check features, look for errors, verify APIs, and apply database migrations. Keep staging as close to production as possible, or you get the classic "works locally, explodes in production."
- Release: Push the built artifacts to the production server, switch traffic, and bump the version. The timing matters for user experience; for a smooth switch see the zero-downtime deployment strategies.
- Run and monitor: Going live is not the end. Watch logs, monitor error rates and resource usage, and be ready to roll back the moment something goes wrong.
Five common deployment methods compared
| Method | How it works | Learning curve | Best for | Downsides |
|---|---|---|---|---|
| Manual | Log in to the server and type commands to pull code and start services | Medium | Single machine, experiments | Easy to skip steps, not reproducible |
| FTP upload | Drag files into the server directory with FileZilla or similar | Low | Static sites, legacy shared hosting | No version control, error-prone |
| Git pull | Run git pull on the server, then restart | Medium | Small teams, hosted repos | Still semi-automated |
| CI/CD pipeline | Commit triggers automated build, test, and release | Medium-high | Larger projects, frequent releases | You must maintain the pipeline |
| Containers | Package the environment with Docker; build once, run anywhere | Medium-high | Environment consistency, microservices | Has a learning curve |
How to choose
- Personal blog or static site: FTP or a managed hosting platform is simplest and gets you live in minutes.
- Small team, WordPress or dynamic site: Start with Git-based deployment — it keeps history and saves effort.
- Project with frequent releases: Introduce CI/CD early and let machines handle build and test; see setting up a CI/CD pipeline.
- Complex environments or many environments: Package with containers so dev, test, and production match exactly; see the Docker website deployment guide.
Your first deployment, step by step
If this is your first deployment, following this order makes mistakes much less likely:
- Prepare the server: Buy it, install a system (Ubuntu/Debian or CentOS-family recommended), configure SSH key login, and disable password login; see server initial setup.
- Install the runtime: Install the web server (Nginx/Apache), language runtime (PHP/Node/Python), database, and extensions per your stack, keeping versions identical to local.
- Get the code up: Git clone onto the server, install dependencies, run database migrations, and configure environment variables (never commit secrets to the repo).
- Configure the domain and HTTPS: Point the domain to the server IP, and use tools like Certbot to issue a free SSL certificate with auto-renewal.
- Start and verify: Start the service, visit the domain, and confirm the homepage, login, and APIs work; then scan the logs for errors.
- Add a safety net: Set up scheduled backups and monitoring alerts, and write down "how to roll back" so you are covered after going live.
FAQ
Q1: Are deployment and release the same thing? Roughly yes, but strictly speaking "release" emphasizes the moment you switch users to the new version — the final step of the deployment chain.
Q2: Do I really need CI/CD? Not necessarily. Manual or Git-based deployment is enough for small projects; adopt pipelines once the project and team grow, so you are not drowning in tooling from day one.
Q3: Can I change things after going live? Yes. Every change follows the same "edit code → test → release" flow; keep the last known-good version around so you can roll back.
Q4: It works locally but fails in production. Why? Check environment differences first: PHP or Node versions, extensions, database versions, and directory permissions — mismatches here are the usual culprits.