Ship and Verify

Step 1: Test recovery

Pemba asked: "If the system breaks, how fast can you get it back?" Answer that with a measurement.

Stop the backend container:

docker stop himalaya-backend

Note the time. Start it again:

docker start himalaya-backend

Hit the health endpoint:

curl http://localhost:3000/api/health

How many seconds from stop to healthy response? Compare that to Pemba's two-day outage last October. The container restarts in seconds because the environment is already captured in the image -- there's no reinstalling, no reconfiguring, no "works on my machine" debugging.

Step 2: Test the development workflow

This is the "changes without breaking production" flow. Make a visible change to the booking form -- update a label, change a color, add a field. Rebuild the frontend container:

docker build -t himalaya-frontend ./frontend

Stop and restart the frontend container with the new image:

docker stop himalaya-frontend

docker rm himalaya-frontend

docker run -d --name himalaya-frontend --network himalaya-net -p 5173:5173 -e VITE_API_URL=http://himalaya-backend:3000 himalaya-frontend

Open the browser and verify the change appears. The live system (the running containers) was never affected until you chose to deploy the new image. This is what Pemba needs -- his developer Raj can make changes, test them in a container, and only deploy when they work.

Step 3: Compare Docker and Vercel

Open materials/deployment-comparison.md.

You've deployed to Vercel in every project so far. Push to GitHub, Vercel builds, the site is live. Now you've containerised an application with Docker. How do they compare?

Docker gives you environment reproducibility. The same image runs the same way everywhere. You control the OS, the runtime, the dependencies. If it works in the container, it works in production.

Vercel gives you managed infrastructure. SSL, CDN, scaling, zero-config deployment. You don't think about servers.

Neither is better. They solve different problems. Pemba's booking system has a backend with a database -- Vercel handles the frontend well, but the Express API and PostgreSQL need an environment Docker provides. Many teams use both.

The containerisation concepts you've learned -- images, layers, build arguments, environment variables, port mapping -- work the same in Docker, Podman, and any OCI-compatible runtime. The OCI standard defines how container images work. Docker is one implementation. A different tool that supports OCI images uses the same concepts with different commands.

Step 4: Run performance checks

Check the containerised application's performance. Open Chrome DevTools and run Lighthouse on the containerised frontend.

Remember: Lighthouse is a lab measurement tool. It runs on your hardware with simulated throttling. The score it gives you is not what Pemba's users experience. Field measurement -- real user data from the Web Vitals library or CrUX data -- captures actual devices and networks. A site that scores 95 in Lighthouse but has slow field metrics on phones over Nepal's mobile networks has a real performance problem that lab testing misses.

Compare the containerised performance to what you've seen before. Is it roughly the same? The container shouldn't significantly affect application performance -- it's running the same code in a reproducible environment, not adding overhead to request handling.

Step 5: Close the project

Send Pemba the recovery time and the development workflow. Tell him how fast the container restarts -- seconds, not days. Show him that his developer can test changes before they go live.

Pemba will respond with relief. Then he'll ask: "Can we also set up something so I know when the system is having problems before a customer tells me?" Last October, a guide told him the booking page was slow before Pemba knew anything was wrong.

That's a reasonable request -- monitoring, alerting, observability. It's also a different piece of work. Acknowledge it, explain it's out of scope for this project, and suggest it for a future engagement. Managing client scope is part of the professional relationship. Not every good idea belongs in the current project.

Push your work to GitHub. Write a README that describes:

• What the project is (containerised booking system for Himalaya Horizon Treks)
• How to build and run the containers
• The recovery time you measured
• What's in each container

Close your tickets. Commit with a clear message.