5.4Deployment & CI/CD (Render, Railway, VPS)
The essentials in 30 seconds
- Deploying = going online: running the app on an accessible server — simple PaaS to start, VPS for control.
- CI/CD = auto delivery: on each push, test (CI) then deploy if everything passes (CD) — no more risky manual deployment.
- Secrets out of the code: config and secrets in environment variables — never in code or in Git.
Running case — Salim goes online in Algiers
Salim's containerised API runs well — but only on the team's machines in Algiers. He deploys it on a platform: connected repository, environment variables filled in on the platform, active HTTPS. Then he adds a pipeline: on each push, tests run, and deployment follows only if they pass. Final episode of cases 5.1-5.3 — Salim delivers a real online service.
Final episode of cases 5.1-5.3 — Salim ties together typing, performance and Docker with going to production.
1. Deploying: PaaS or VPS
Deployment runs the application on a server accessible over the Internet (instead of localhost). PaaS platforms simplify everything: you connect your Git repository, the platform builds, launches, manages the server, HTTPS and basic scaling — with an affordable entry level to start — ideal for beginners. At the other end, a VPS (a rented virtual server) gives more control but more responsibilities: installing Node, configuring, securing, managing PM2, a reverse proxy, HTTPS — more complex, but instructive. The big clouds offer a powerful range with a learning curve. Salim starts with a PaaS: his API is online by following the platform's documentation, without administering a server.
Recommendation: PaaS to put your projects online fast, VPS to learn administration or gain control, cloud for advanced needs.
2. CI/CD and production essentials
CI/CD automates the path from code → production. Continuous integration: on each push, a pipeline runs tests and linting to catch problems early. Continuous deployment: if everything passes, the code is deployed automatically. GitHub Actions creates these pipelines. Benefits: automation (no more tedious manual steps), reliability (nothing broken goes to production), speed (shipping often with confidence), traceability (each deployment linked to a commit). Essentials: environment variables (config + secrets, never in code/Git), HTTPS, logs and monitoring, separate environments (dev/staging/prod). Salim writes his first pipeline: install, test, deploy if green — it is the culmination, not only creating but delivering.
Even a simple pipeline changes everything: tests are never “forgotten” before a deployment again.
3. Choosing without going wrong
The fundamental trade-off: simplicity versus control. PaaS: extreme simplicity, less fine control, dependence on the platform — perfect for starting out and for many projects. VPS: total control and flexibility, but you manage everything (security, updates, backups) — instructive, more demanding. For a prototype or an exercise, a manual deployment is enough; as soon as a project is serious, deployed regularly or as a team, even a simple CI/CD brings real value. Salim compares hosts' offers (plans and limits often change, so he checks the current documentation when choosing) and gets sensitive infrastructure choices validated by his IT department before exposing real data.
In all cases, the essentials remain: secrets in environment variables, HTTPS, logs and monitoring, separate environments.
🔎 Concrete example — Salim's pipeline
On each push: install, test, deploy if green.
# GitHub Actions (.github/workflows/ci.yml)
# on each push:
# npm install → npm test → deploy if green
# secrets & config: the platform's environment variables
# PaaS: builds from the repo, auto HTTPSReading: the pipeline is the gate: nothing broken gets through.
Lesson: secrets live in the environment, never in the code.
Section vocabulary
- Deployment
- Running the app on a server accessible over the Internet.
Simple example: Salim's API leaves localhost for a public address.
What it is not: copying files by hand with no pipeline.
Reflex: is my app accessible outside my machine?
- PaaS
- Platform that builds and hosts the app from the Git repository.
Simple example: Salim connects his repository, the platform manages server and HTTPS.
What it is not: a server you administer yourself.
Reflex: do I need control, or simplicity?
- VPS
- A rented virtual server you administer yourself.
Simple example: Salim would install Node, PM2 and HTTPS on it himself.
What it is not: a platform that manages the infrastructure.
Reflex: am I ready to take on security and maintenance?
- CI/CD
- Pipeline that tests on each push and deploys if everything passes.
Simple example: Salim's push triggers tests then automatic going online.
What it is not: a manual deployment with command lines.
Reflex: can a push reach prod without tests?
- Environment variables
- Config and secrets provided by the environment, out of the code.
Simple example: Salim's key lives on the platform, never in Git.
What it is not: a secret hard-coded in the code.
Reflex: is a secret lying around in my repository?
In practice — Deploy and automate an application
- Deploy a Node application on a simple PaaS platform: connect your Git repository, the platform builds and launches the application, with HTTPS.
- Configure environment variables on the platform (secrets, config) — never in code or Git.
- Set up a CI/CD pipeline (GitHub Actions): on each push, run the tests and automatically deploy if everything passes.
- Ensure the production essentials: HTTPS, logs/monitoring, and separate environments (dev/staging/prod).
Ready-to-say script — announcing going online
“Our API is ready to leave localhost: I'm deploying it on a platform — connected repository, secrets in environment variables, active HTTPS. I'm adding a simple pipeline: tests on each push, deployment only if everything passes. Before exposing real data, I'll get the infrastructure choice validated by the IT department.”
To say to your manager to get going online and the IT-department circuit on sensitive data approved.
Copy-paste template — generic CI pipeline
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm install
- run: npm testSolo / small budget
Salim alone: a PaaS + a pipeline that tests on each push is enough — no server to administer.
Small business / small team
Separate dev and prod environments, secrets on the platform: each push tested before going online.
SME in Algiers
Salim gets the host and access approved by the IT department in Algiers before exposing real customer data.
Team starting out
Pair: one writes the pipeline, the other checks secrets and HTTPS; review before the first auto deployment.
✓ Best practices
- Start with a PaaS platform: simple, HTTPS managed.
- Put config and secrets in environment variables (never in Git).
- Automate tests + deployment with a CI/CD pipeline (GitHub Actions).
✗ Common pitfalls
- Putting secrets in code or the Git repository.
- Deploying without HTTPS (passwords and data in plain text).
- Deploying manually and blind (with no automated tests upstream).
Key takeaways
- DEPLOYMENT: running the app on an accessible server (instead of localhost). PaaS (simple) or VPS/cloud (more control).
- CI/CD (GitHub Actions) automates code → production: CI (test on each push), CD (deploy if everything passes). Automation, reliability, speed, traceability.
- Production essentials: ENVIRONMENT VARIABLES (config + secrets, never in code/Git), HTTPS, logs/monitoring, separate environments.
- It is the culmination of the journey: not only CREATING an application, but DELIVERING it — a real, online, reliable service.
48h challenge — apply tomorrow
Deploy 1 app on a platform (connected repository + HTTPS) with its secrets in environment variables: does a push trigger the tests?
- I can explain CI vs CD in one sentence.
- My app is online (HTTPS) with no secret in Git.
- I know when to move from PaaS to VPS.
Frequently asked questions
PaaS, VPS or cloud: how do I choose where to deploy my Node application?
It depends on your need and level. PaaS platforms simplify enormously: you connect your Git repository, the platform builds and launches the application, manages the server, HTTPS and basic scaling — ideal for starting out and for many projects. A VPS (rented virtual server) gives more control but more responsibilities: you administer everything (Node, PM2, reverse proxy, HTTPS) — more complex, but instructive. The big clouds offer a powerful range with a learning curve. Recommendation: start with a PaaS to put your projects online; move to a VPS to learn administration; explore the cloud for advanced needs. Compare offers when choosing (they change) and get validation from the IT department before exposing sensitive data.
Why set up CI/CD, and is it necessary for small projects?
CI/CD automates the path from code to production: CI (on each push, the pipeline checks — tests, linting), CD (if everything passes, auto deployment). Benefits: automation (no more tedious, risky manual work), reliability (nothing broken goes to production), speed (shipping often with confidence), traceability (each deployment linked to a commit). For a throwaway prototype, not strictly necessary. As soon as a project is serious, deployed regularly or as a team, even a simple pipeline brings real value. Start simple: install, test, deploy if everything passes.
What does a CI/CD pipeline do?