DevOps project
Containerize and deploy an app to a live URL
Turning an existing app into a properly built, small Docker image and getting it live on a real host — the actual entry-level DevOps skill almost every posting lists.
The brief
Take an existing small app (your own frontend or backend project is fine) and containerize it: write a multi-stage Dockerfile that keeps the final image small, set up docker-compose for local development including a database container, and deploy the containerized app to a free-tier host (Render, Fly.io, or Railway) so it's reachable at a real URL.
Suggested stack
What you hand in
- A public GitHub repository with the Dockerfile, compose file, and a README
- A live URL where the deployed app can be reached
- The README documents image size before/after multi-stage optimization and the deploy steps
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
Uses a multi-stage build, a slim base image, a .dockerignore, and doesn't ship build-time-only tools or dev dependencies in the final image.
docker-compose up brings up the app and its database with correct networking and environment variables, reproducibly on a machine that's never seen the project.
The app is reachable at a real URL and functions correctly there, not only on localhost.
A reader who has never seen the repo can build, run, and deploy it by following the README alone.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Containerizing an app is the entry-level DevOps skill listed on nearly every job posting, engineering or DevOps alike.
- A live URL is undeniable proof the work actually functions, unlike a screenshot or a claim in a README.
- Image size and multi-stage build discipline is the detail that separates a copy-pasted Dockerfile from an understood one, and it's checkable with `docker images`.
Where people lose points
- Copying the entire project — including node_modules and .git — into the image because there's no .dockerignore.
- Running the app as root inside the container instead of a non-root user.
- Skipping the multi-stage build, so the final production image still ships compilers and dev dependencies it never needs at runtime.
Other DevOps projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.