Shipping Web Apps to a VPS Should Be This Simple

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:

1. Build locally
2. Package the output
3. Upload it over SSH/SFTP
4. Unpack it on the server
5. Start the new version
6. 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.