Tako vs CapRover for VPS Apps

CapRover is one of the friendliest open-source ways to turn a VPS into a self-hosted PaaS. Install it, point a wildcard domain at the box, open the dashboard, and you get app deploys, domains, HTTPS, logs, environment variables, Docker images, and one-click apps in a browser.

That is a good product shape. It gives people a home base.

Tako starts from a different bet: the center of gravity should be your repo, your terminal, and your app runtime. The platform should still handle the annoying parts — deploys, routing, TLS, secrets, logs, scale-to-zero, workflows, and now opt-in containers — but the primary interface should be a small CLI and a versioned tako.toml.

Same VPS instinct. Different control surface.

At A Glance

CapRover is closer to a mini Heroku dashboard for your own box. Tako is closer to an app platform layer that happens to live on your own box.

CapRover’s Sweet Spot

CapRover shines when you want a visual control panel for a server. You can create an app, attach a domain, enable HTTPS, set environment variables, inspect logs, scale instance count, and deploy Docker-based workloads without building your own nginx or Docker Swarm wiring.

It also has a broad app surface. The CapRover one-click app model can deploy images and Compose-shaped templates, which makes it useful for WordPress, databases, dashboards, and packaged open-source services. If your goal is “I want my VPS to have a place where I can install and manage lots of server software,” CapRover has the right mental model.

The deployment model is also flexible. CapRover documents multiple paths: CLI deploys, dashboard uploads, CI/CD flows, Docker images, and captain-definition files. A heterogeneous team can use a browser for day-to-day management and still automate deploys later.

That dashboard-first model is the point. It gives you an admin surface for the whole machine.

Where Tako Is Different

Tako keeps the machine mostly out of sight. A project carries its deployment shape in config:

name = "api"
runtime = "bun"
main = "src/index.ts"

[envs.production]
route = "api.example.com"
servers = ["prod"]
idle_timeout = 300

Then the workflow is boring:

tako secrets set DATABASE_URL --env production
tako deploy
tako logs --env production --tail

The server is still doing real platform work. It runs the Pingora proxy, terminates TLS, tracks app instances, performs health checks, stores secrets encrypted server-side, streams logs, and rolls releases forward only after fresh instances are healthy. But the source of truth is the repo plus the CLI, not a browser dashboard database.

The native deploy path is the other big difference. CapRover is Docker-first. Tako defaults to native processes for the runtimes it knows deeply: Bun, Node, and Go. A deploy builds locally, uploads a compressed artifact over SFTP, runs production install when needed, and starts the app directly under tako-server. The deployment docs spell out the full release flow.

That matters for small VPS apps because most of them do not need a container boundary. They need a good proxy, HTTPS, secrets, logs, health checks, and a reliable rolling update.

Tako now has an answer for Dockerfile-shaped apps too. Set:

runtime = "go"
container = "Dockerfile"
dev = ["go", "run", "."]

With container = "Dockerfile", production deploys package source for a container release. The server builds the image with Podman, starts HTTP containers from the image defaults, and still keeps Tako routing, TLS, secrets, logs, and rolling updates around it. Containers are not the default abstraction, but they are available when they are the honest fit.

Platform Primitives, Not Just App Starts

CapRover is a strong app and service manager. Tako is deliberately narrower on server administration and deeper on app runtime primitives.

Scale-to-zero is a good example. In Tako, a deployed app has a persistent desired instance count. New apps start warm, but you can opt into on-demand serving:

tako scale 0 --env production

When desired instances are 0, the server can stop idle HTTP instances after the app’s idle timeout and cold-start them on the next request. That is useful for preview apps, staging routes, admin tools, webhook handlers, and the dozen tiny services that do not need to burn memory all day.

Workflows are another example. CapRover can run worker containers, and that is a perfectly normal Docker answer. Tako adds durable workflows to the app model itself. JavaScript apps define workflow files under <app_root>/workflows/; the server owns the queue, retries, step checkpoints, schedules, and worker lifecycle. Workers can scale to zero separately from HTTP traffic. The how Tako works guide covers the runtime protocol behind that.

Secrets also show the difference. CapRover exposes environment-variable configuration for apps. Tako stores project secrets encrypted in .tako/secrets.json, validates expiry during deploy, sends secret updates over signed management paths, stores them encrypted on the server, and injects them into fresh app processes through the SDK bootstrap envelope. Native processes receive fd 3; container releases receive TAKO_BOOTSTRAP_DATA. App code reads tako.secrets or generated Go helpers, not plaintext files.

The pattern is consistent: CapRover gives the operator a dashboard for containers and services. Tako gives the app a runtime contract.

Choose The Shape You Want

Choose CapRover if you want a dashboard PaaS for a VPS, you like Docker as the universal app boundary, you want one-click apps and packaged services, or your team prefers browser-based operations. It is friendly, practical, and broad.

Choose Tako if your deploy workflow should live in git, your team prefers a CLI, you want native deploys for Bun, Node, or Go, you care about local dev with real HTTPS, or you want app primitives like scale-to-zero and durable workflows without assembling another stack.

And if the thing you need is a Dockerfile, Tako does not make you leave. Use a container release, keep the Dockerfile, and let Tako keep handling the platform layer around it.

That is the difference we are building around: not a bigger dashboard than CapRover, but a smaller control surface around a deeper app runtime.