I'm building my first production SaaS application with a Turborepo monorepo and Next.js. I've been assuming that the frontend, backend, and database should all be containerized, and that Docker setup should happen before serious development begins.
The issue is that I'm currently using a Chromebook with only 4 GB of RAM, so running Docker locally isn't practical. I may eventually get a more powerful machine, but I'd like to keep working in the meantime.
Would it be reasonable to run the application directly on the development machine for now and containerize it closer to launch? What drawbacks should I expect, and would this require major changes to the application or deployment setup later?
4 Answers
If you’re not collaborating or deploying yet, postponing Docker is a reasonable choice. If you are sharing the project or want to test deployments, your CI pipeline can build and publish the container remotely, so Docker doesn’t have to run on the Chromebook.
It’s also worth following twelve-factor principles from the beginning: keep configuration outside the code, make services stateless where possible, and avoid relying on machine-specific paths or installed software. That makes containerizing later much smoother. For a multi-service project, a Compose configuration can eventually provide convenient service discovery and networking, but you don’t have to start there.
You don’t necessarily need to run the development environment on the Chromebook itself. Treat it as a lightweight terminal and connect to a stronger remote environment instead. A cloud development workspace, a hosted Linux VM, or another remote coding platform could give you enough resources to use Docker without buying a new device immediately.
Running directly on the machine is generally fine during development. You may need some configuration changes later, such as moving secrets into environment variables, ensuring the app listens on the correct interface and port, handling file paths properly, and making sure services can communicate over a network instead of through localhost.
Those changes are usually manageable, but testing against an environment close to production earlier will reduce surprises. You probably won’t face a major rewrite, though the exact risk depends on how many services and infrastructure dependencies your app has.
You can absolutely develop without containers, especially if you’re working alone. The main benefit of starting with Docker is finding environment and deployment problems earlier. If you later add services such as Redis, a database, or a worker, containers can make local setup much easier than installing everything separately.
Also, Docker isn’t mandatory for every deployment. Depending on your hosting choice, a platform such as Vercel or another managed service may remove the need to maintain your own containers entirely. Decide where you want to deploy before treating Docker as a requirement.

Would GitHub Codespaces be a reasonable budget option for this, or are there better alternatives for a small project?