惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
GbyAI
GbyAI
Google DeepMind News
Google DeepMind News
Jina AI
Jina AI
B
Blog
aimingoo的专栏
aimingoo的专栏
酷 壳 – CoolShell
酷 壳 – CoolShell
T
The Blog of Author Tim Ferriss
Last Week in AI
Last Week in AI
月光博客
月光博客
H
Help Net Security
V
Visual Studio Blog
量子位
A
About on SuperTechFans
博客园 - Franky
人人都是产品经理
人人都是产品经理
N
Netflix TechBlog - Medium
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
P
Proofpoint News Feed
MongoDB | Blog
MongoDB | Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Shipping Web Apps to a VPS Should Be This Simple
Dan · 2026-05-03 · via DEV Community

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

Enter fullscreen mode Exit fullscreen mode

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"]

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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/

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.