Your app just started to pick up traffic, and you are looking to scale it with Docker and Kubernetes. A Google search for Docker images gives you plenty of selections. Sometimes too many. Other times, you can't find the right one. Even when you do, it doesn't match your local environment.
Our struggles with containers at Jetpack.io
Two weeks ago, our website almost went down due to a mismatched version of Node.js between production and our development environments. At Jetpack, front-end projects and web apps are developed locally and deployed to Kubernetes in Docker containers. One day, a babel plugin threw an error when deploying to production. It turns out that the Node-16:alpine image upgraded the Node.js version from 16.16 to 16.17 silently. We now have a mismatched Node.js version between our local dev environments and the ones in Docker containers.
We created Devbox to build Docker images from scratch
To address the above pain points, we built Devbox. Devbox builds any Docker image from scratch. You no longer need to worry about compatibility with the base image since Devbox bundles the exact dependencies you need to run your applications. In fact, no base image is required at all.
Devbox matches local shell environments to production
Using the Nix package manager, Devbox spins up a Nix shell for local development or a Docker image for remote deployments. No need to run a docker container locally to develop your code anymore, since Devbox uses the same package and its dependencies in both your shell and container.
How are we planning to use Devbox at Jetpack.io?
In the next few weeks, we will use Devbox as our primary development environment and in the GitHub CI/CD production pipeline for all our repositories. Some parts of our codebase still rely on containers for development, which takes a long time to build and eats up all the memory and CPU of our laptops. We hope by using Devbox, we can move towards faster and more reliable dev and prod environments for all of our infrastructure.