Forem: Dan

Why I Don’t Want Docker to Be the Default Deploy Path

Dan — Sun, 03 May 2026 00:19:30 +0000

Docker is good software.

I want to say that up front because the internet has a special talent for turning every tooling opinion into a cage match.

I use Docker. I like Docker for databases, repeatable CI jobs, weird dependency stacks, internal services, and anything where I need a clean system image that behaves the same everywhere.

But I do not want Docker to be the default deploy path for every web app.

Sometimes I just want to put an app on a VPS and have it run.

That should feel boring.

The default path got heavier

A lot of modern deploy tutorials quietly turn this:

build app
copy files to server
start app
route traffic

into this:

write a Dockerfile
pick a base image
handle build layers
create a registry
push an image
pull it on the server
wire up compose
configure networking
mount secrets
debug why the container exits

None of those steps are evil.

They are just a lot.

And for many apps, they are not the interesting part.

If I am deploying a side project, a SaaS, a webhook handler, a dashboard, or a little internal tool, the app usually needs a few simple things:

build the code
start the process
serve HTTPS
restart when it crashes
keep secrets out of git
show logs when something breaks
maybe run a few apps on the same machine

That list does not automatically mean "containerize everything".

Containers solve real problems

This is not an anti-Docker post.

Docker solves problems that are absolutely real.

It gives you a repeatable runtime. It makes system packages less mysterious. It can isolate services from each other. It makes CI easier. It gives teams a common artifact they can pass around.

That is useful.

But defaults matter.

When Docker becomes the first step for every deploy, even tiny apps inherit container concerns before they have container problems.

Now the developer is thinking about image size, build cache, multi-stage builds, registry auth, container networking, volume paths, base image updates, and whether the process can find the right port inside the container.

Again, all valid stuff.

Just not always the first stuff.

A VPS can run normal processes

The funny thing is that a VPS is already a computer.

It can run a process.

That sounds obvious, but a lot of modern deployment advice treats a server like it is only useful once it is running a container scheduler.

For many apps, a direct process model is enough:

bun run start
node server.js
./my-go-app
./target/release/my-rust-app

The hard parts are not usually "can Linux run this binary?"

The hard parts are everything around it:

how does traffic reach it?
how does HTTPS work?
how do I deploy a new version without downtime?
where do logs go?
how do secrets get injected?
how do I restart it?
how do I run multiple apps on one box?

Those are deployment problems, not necessarily Docker problems.

I want the PaaS feeling without giving up the server

This is the thing I keep wanting.

I like the feel of a PaaS:

deploy

and then the app is live.

But I also like owning a VPS. It is cheap, flexible, and boring in a good way. I know where the app is running. I can SSH in. I can inspect the machine. I am not turning every weekend project into a cloud architecture diagram.

So the ideal flow, at least for me, looks more like this:

tako deploy

Local machine builds the app. The deploy tool copies the release to the server. The server runs the app as a normal process. A proxy routes requests to healthy instances. HTTPS is handled. Logs are available. Secrets are managed outside random .env files.

No image registry needed.

No Dockerfile unless I actually want one.

No container networking puzzle for a two-route web app.

That is the direction I have been exploring with Tako, which is a deployment tool for running apps on your own servers.

The boring path should be the happy path

There is a version of deployment that feels almost disappointingly plain:

tako init
tako servers add
tako deploy

That is the kind of boring I want.

Not boring as in weak or limited.

Boring as in:

fewer concepts before the first deploy
fewer files created only for infrastructure
fewer moving parts for apps
fewer places where a simple mistake hides
fewer "wait, is this a Docker problem or an app problem?" moments

I think the default path should optimize for the app getting online first.

Then, if the app grows into container needs, reach for containers.

Docker should be an option, not the entrance fee

The web has a habit of turning powerful tools into mandatory tools.

Docker is powerful. It deserves its place.

But I do not think every deploy should start by asking the developer to write a container recipe.

For a lot of projects, the best deploy path is still:

build the app
put it on a server
run it
route traffic to it
make updates boring

That is not old fashioned. That is just a good abstraction.

The default deploy path should feel calm.

It should feel like the server is helping you run your app, not asking you to become a platform engineer before lunch.

Shipping Web Apps to a VPS Should Be This Simple

Dan — Sun, 03 May 2026 00:12:44 +0000

I like servers.

Not in a "let me spend Saturday hand-tuning nginx" way. More in a "this $6 VPS is sitting right here and could probably run half my side projects" way.

The weird part is that deploying to one still feels more complicated than it should.

For a lot of small and medium web apps, the app itself is not the hard part. The annoying part is everything around it:

building the app
getting it onto the server
starting it without dropping requests
setting up HTTPS
keeping secrets out of random .env files
seeing logs without SSH archaeology
making local dev look enough like production that cookies and OAuth stop being weird

None of that is impossible. It is just a bunch of little chores stacked on top of each other.

That pile of chores is why I started working on Tako.

The thing I wanted

I wanted deployment to feel closer to this:

tako init
tako deploy

Not because two commands are magical, but because most apps don't need a custom infrastructure thesis before they can serve HTTP.

Tako is a CLI plus a tiny server runtime. You install the server once on your VPS, add that server locally, then deploy from your project directory.

The deploy flow is intentionally plain:

Build locally
Package the output
Upload it over SSH/SFTP
Unpack it on the server
Start the new version
Roll traffic over without dropping the old version first

No registry. No image push. No Kubernetes object graph. No "where did this container layer come from?" moment at 1:12 AM.

That doesn't mean Docker is bad. Docker is great when you need it. I just don't think every JavaScript app should have to start there.

Running the app as an app

Tako runs your app as a normal process.

For JavaScript and TypeScript apps, there is a small tako.sh SDK. Your app tells Tako when it is ready by reporting the port it bound to. Then the server proxy can safely route traffic to it.

In production, app instances bind to 127.0.0.1 on an assigned port. Tako's proxy sits in front, handles the public route, and forwards requests only to healthy instances.

That setup makes a few things pretty simple:

rolling deploys can start a new instance before removing the old one
low-traffic apps can opt into scale-to-zero
logs and status can be attached to the process Tako actually started
the app doesn't need to know what public port or hostname it lives behind

The config is meant to stay boring too:

name = "my-app"
runtime = "bun"
preset = "tanstack-start"

[build]
run = "bun run build"

[envs.production]
route = "my-app.example.com"
servers = ["main"]

There's more available when you need it, like multiple environments, multiple servers, build stages, release commands, secrets, and scale settings. But the basic shape is just "here is my app, here is where it should run."

Local dev should not be localhost soup

One thing that kept bugging me was local development.

Most deploy tools stop at production. That's fair, but it leaves you with the classic mess:

http://localhost:3000
http://localhost:5173
http://localhost:8787

Then one day you need secure cookies, OAuth callbacks, service workers, a second app, or a webhook tunnel, and suddenly your local setup has its own personality.

tako dev tries to make local apps feel like real apps:

tako dev

That gives your app a .test domain with HTTPS, DNS, and a local proxy. So instead of remembering a port, you open something like:

https://my-app.test/

The goal isn't to be fancy. The goal is to remove the tiny paper cuts that make local dev drift away from production.

The tradeoffs

This isn't a universal tool.

If your app needs heavy OS-level isolation, containers might be the better answer. If your team already has a container pipeline that works, you probably shouldn't throw it away for fun. If you're running a bunch of unrelated stacks with weird system packages, Docker is a very reasonable boundary.

Tako is more opinionated. It focuses on common web app runtimes like Bun, Node, and Go, then tries to make that path fast and calm.

That tradeoff is the whole point.

I don't want to rebuild a container platform. I want a small tool that makes a VPS feel useful again.

Try it

The project is open source here:

https://github.com/lilienblum/tako

Docs are here:

https://tako.sh/docs

The quick version looks like this:

curl -fsSL https://tako.sh/install.sh | sh
tako init
tako dev

And when you're ready to put it on a server:

sudo sh -c "$(curl -fsSL https://tako.sh/install-server.sh)"
tako servers add <host-or-ip>
tako deploy

It's still early, but it's already scratching the itch I built it for: shipping normal web apps to normal servers without turning every deploy into infrastructure cosplay.