5. Deploying a simple app

Deployment is the process of making your application available on a server that other people can reach over the internet.

While you are building an app, you run it on localhost — your own computer, accessible only to you. When you deploy, you copy your code (and all its dependencies) to a remote server, start the application there, and point a public address at it so visitors can find it.

Think of it like this: you bake injera at home (development), then open a restaurant on a busy street in Addis Ababa so customers can come and eat it (deployment). The recipe is the same, but now the world can reach it.

The three big questions of any deployment are:

1. Where will the app run? (your cloud hosting choice)

2. How will users find it? (your domain name and DNS)

3. How will it stay running safely? (environment variables, HTTPS, and monitoring)

Your first decision is where to run your app. In earlier lessons you learned about VPS, managed hosting, and platform-as-a-service (PaaS). For a first deployment, the main options are:

Managed PaaS (e.g. Render, Railway, AletCloud Apps)

You push your code and the platform handles the server, OS, and runtime for you. Best for getting started fast — Abebe's first side project was live in under ten minutes on a PaaS. The trade-off is less control and slightly higher cost at scale.

VPS (e.g. AletCloud VM, DigitalOcean Droplet)

You rent a virtual machine and manage everything yourself — install Node.js or Python, configure a web server (Nginx or Caddy), set up HTTPS with Let's Encrypt, and keep the OS updated. More control, lower cost at scale, but more setup work.

Serverless functions (e.g. Vercel, AWS Lambda)

Your code runs only when a request arrives; you pay per execution. Great for apps with unpredictable traffic, but not every app fits the serverless model.

For this lesson we will follow the most common beginner path: deploying a Node.js web app to a managed PaaS, then pointing a custom domain at it.

Before you push code to a production server, you need to make a few important changes to how your app is configured.

Environment variables

When you develop locally, you might hardcode things like database passwords or API keys directly in your code. Never do this in production — if your code is ever public (on GitHub, for example) your secrets are exposed.

Instead, store secrets as environment variables — values set on the server that your code reads at runtime. Every PaaS and VPS has a panel where you set these. In your code you read them like this (Node.js example):

const dbPassword = process.env.DB_PASSWORD;

const apiKey = process.env.TELEBIRR_API_KEY;

Create a file called .env for local development, but add .env to your .gitignore file so it is never committed to version control.

Production vs development mode

Many frameworks (Next.js, Express, Django, etc.) behave differently when NODE_ENV=production is set. In production mode, verbose error messages are hidden from users (important for security), and the app is optimised for speed. Always set NODE_ENV=production on your production server.

Start and health-check commands

The hosting platform needs to know two things: how to start your app (the start command, e.g. node server.js or npm start) and how to check if it is still running correctly (a health check endpoint, usually a GET /health route that returns 200 OK).

Here is a concrete walkthrough of deploying a simple Node.js/Express app to a managed PaaS. The exact clicks differ by platform, but the logical steps are the same everywhere.

Step 1 — Push your code to a Git repository

Create a repository on GitHub (or GitLab). Push your project code. Make sure .env is in .gitignore so your secrets never leave your machine.

Step 2 — Create a new app on the platform

Sign in to your PaaS dashboard (e.g. AletCloud, Render). Click "New App" and connect it to your Git repository. The platform will detect your project type automatically (Node.js, Python, etc.).

Step 3 — Set environment variables

In the platform's environment variables section, add all the variables your app needs:

DB_URL = postgresql://user:password@host:5432/mydb

PORT = 8080

NODE_ENV = production

Note: On AletCloud and many other platforms, the app must listen on port 8080 specifically — check your platform's documentation.

Step 4 — Trigger a deployment

Click "Deploy" (or push a new commit — most platforms auto-deploy when you push to the main branch). The platform clones your code, installs dependencies (npm install), runs your build command if any (npm run build), then starts the app (npm start).

Step 5 — Check the logs

Every PaaS shows real-time build and runtime logs. If the deployment fails, the logs tell you exactly why — a missing environment variable, a syntax error, a port mismatch. Read the logs carefully; they are your first debugging tool.

Step 6 — Open the generated URL

The platform assigns a URL like myapp.aletcloud.app or myapp.onrender.com. Open it in your browser — if you see your app's home page, the deployment succeeded!

Your app is live, but the address the platform gave you (myapp.aletcloud.app) is hard to remember and looks unprofessional. You want a custom domain like sara-store.et or abebe-tech.com.

Here is how to connect a domain to your deployed app:

1. Register your domain

Buy a domain from a registrar. In Ethiopia, .et domains are managed through the EthioNIC registry (contact your ISP or a local reseller). For international domains (.com, .app, .io), use services like Namecheap or Cloudflare Registrar.

2. Add a custom domain in your PaaS dashboard

In your app's settings, find the "Custom Domains" or "Domains" section. Enter your domain name (e.g. sara-store.et). The platform will give you either an IP address or a CNAME value to set in your DNS records.

3. Update your DNS records

Log into your domain registrar's DNS management panel. Add a new record:

• If the platform gave you an IP address: create an A record pointing sara-store.et → IP address

• If the platform gave you a CNAME value: create a CNAME record pointing www.sara-store.et → the platform's CNAME value

4. Wait for DNS propagation

DNS changes take anywhere from a few minutes to 48 hours to spread around the world (this is called DNS propagation). Usually it is under 30 minutes.

5. Enable HTTPS

Most PaaS platforms automatically provision a free TLS certificate (via Let's Encrypt) once your domain is pointing at them. When you see the padlock icon in your browser after visiting your domain, HTTPS is working.