open source · no cluster required
One command. It's live.
Chasen deploys backend services, full-stack apps, and websites to one server. HTTPS, zero-downtime deploys, and backups come built in. That is plenty for the rest of us.
$ curl -fsSL chasenhq.com/cli | sh$ chasen deploy #4 [2/3] COPY . /app #5 [3/3] RUN bundle install #6 exporting to image shop: backup 20261001T120000Z (on the server and offsite) Starting shop 3f9a2c1 Deployed shop 3f9a2c1 https://shop.apps.example.com $
[01] the premise
You don't need Kubernetes to start a business.
You need one server, a way to deploy to it, and backups you can restore. Most businesses never outgrow that. If yours does, it is a good day: you have the customers to pay for the next step.
[02] what ships
If it has a Dockerfile, it ships.
Backend services, full-stack apps, and frontend repos deploy the same way: cd into the folder, run chasen deploy. Each one gets its own domain and its own HTTPS certificate.
- Four rules are the whole contract. There is no build pack and no YAML pipeline.
- Secrets come from fnox, 1Password, or sops at deploy time. They never enter git or the image.
- The server builds the image from the commit you deploy. Your machine needs no Docker.
[03] addons
Logs, analytics, and forms. One command each.
A business needs more than its own app. Chasen runs these next to it, on the same server, with a domain, HTTPS, and the same backups. No source, no build.
$ chasen enable lognorth Pulling karloscodes/lognorth:latest Starting lognorth Enabled lognorth https://lognorth.apps.example.com
- Run
chasen enableagain to update an addon to its newest version. - LogNorth pings your apps every minute and tells you when one stops answering.
[04] backups
The database is backed up before every deploy.
One server with SQLite is only safe with backups you can restore. Each hour and before each deploy, Chasen copies every database, runs an integrity check on the copy, and sends it to your S3 bucket. Between two copies, a live replica streams every change to the bucket.
$ chasen backups 20261001T120000Z server + offsite 20261001T110000Z server + offsite 20261001T100000Z server + offsite live offsite, continuous $ chasen restore 20261001T110000Z Restored shop from 20261001T110000Z. The previous databases are in /var/matcha/shop/pre-restore-20261001T121502Z
- One second behind. Litestream runs inside Chasen. It reads the write-ahead log of each SQLite database and sends the new changes to your bucket once every second. If the server dies this instant, you lose the writes of about the last second, not of the last hour.
- Checked. A copy that fails the integrity check is not a backup. A failed backup stops the deploy.
- Kept. The newest copy of each of the last 24 hours, 7 days, 4 weeks, and 6 months.
- Nothing deleted. A restore moves the current database aside. It does not overwrite it.
- The server can die. Set up a new one with the same bucket and run
chasen deploy. The data comes back first. - Every database. An app with several SQLite files, like Rails with its cache and queue, gets all of them backed up and restored together.
- Any S3-compatible bucket. Cloudflare R2, Backblaze B2, Hetzner, or S3.
[05] day two
The whole CLI fits on one screen.
There is no dashboard to learn. Every deploy, restore, and domain change is recorded with its output, so chasen history is the feed.
Usage: chasen <command> login Log in to the Chasen cloud, with a browser add server <domain> Use your own server instead, and log in to it Run these in the directory of your app: deploy Deploy the current git commit status Show the version, the URLs, and the last backup logs Follow the app logs history [id] Show the deploys and changes, or the output of one domains add <domain> Add a custom domain. No rebuild, no downtime backup Back up the SQLite databases now backups List the backups restore [backup] Restore a backup remove Stop the app. Keeps the data and the backups
ID WHEN (UTC) ACTION RESULT 5 2026-10-01 12:03:21 deploy 6cff7df failed 4 2026-10-01 12:03:02 restore succeeded 3 2026-10-01 12:02:44 domains add shop.com succeeded 2 2026-10-01 12:02:24 deploy ca93d35 succeeded 1 2026-10-01 12:02:09 deploy 727846a succeeded
- A deploy that does not answer
/upin 30 seconds fails safe: the old version keeps the traffic. - A deploy runs to its end on the server, also when your connection drops.
[06] pricing
Bring your server, or we give you one.
Run it on your own server for free. Or skip the server work and pay two things: €9 a month for Chasen, and the server you pick, at the price Hetzner charges for it.
# on the server: chasen-server
curl -fsSL chasenhq.com/server | sh
chasen-server setup --domain apps.example.com
# on your machine: the chasen CLI
curl -fsSL chasenhq.com/cli | sh
chasen add server apps.example.com
chasen deploy
- as many apps and addons as the server holds
- your whole team, no seats
- nothing metered
# on your machine: the chasen CLI
curl -fsSL chasenhq.com/cli | sh
chasen login
chasen deploy
# the first deploy creates your server.
# one server for you alone, not a shared one.
Without VAT. No server markup. Hetzner's prices →
[07] questions
Plenty for the rest of us.
Chasen leaves things out on purpose. Each one is something you don't have to run, pay for, or wake up for.
Is one server really enough?
To start a business, yes. One modern server runs many apps, and more traffic than most new products see in their first years. The day one box is truly not enough, you have customers, revenue, and a good reason to hire help. Your apps are plain Docker images, so they move anywhere.
Why SQLite and not Postgres?
Because SQLite is a file. There is no database server to run, tune, or pay for. A backup is a copy of that file and a restore puts it back, so Chasen does both for you and checks the copy. An app that needs Postgres still deploys and talks to a database you host elsewhere. Chasen backs up the SQLite files.
What happens when the server dies?
It is rare. A Hetzner server can die, but most never do, and when you are starting a business it is a risk you can afford. If it happens, you get a new server and run chasen deploy. With a backup bucket set, the data comes back first, about one second old. There is no failover cluster to operate, because recovery is one command.
Should I put Cloudflare in front?
We recommend it. It is free and optional. Turn the proxy on for your domains and set the SSL mode to Full (strict). You get two things. Visitors see Cloudflare's addresses, not your server's. And Cloudflare caches your images, scripts, and styles at its edge, so most requests of a traffic spike never reach your server. Pages that your app renders still come from the server, unless you add a cache rule for them. Chasen keeps its own certificate, so the connection stays encrypted the whole way.
How is this different from Vercel?
Vercel bills by seat and by use: $20 a month for each developer, then a meter on requests, data transfer, and CPU time. It can take more traffic than one server, and it charges you for every bit of it: a spike is served, and then it is on the invoice. Chasen is €9 a month plus one server at Hetzner's price. Teammates, more apps, a database, and a busy day do not change that number. With Cloudflare in front, its cache takes most of a spike for free. What a server cannot do is grow by itself: past its limit it gets slow, and you move to a bigger one. To be fair on the rest: for one person with one app, the two cost about the same. Chasen wins from the second teammate or the second app. Custom domains are free on both. If your product is a frontend for a world-wide audience, stay on Vercel. If it has a backend and a database, a server does more for the money.
How do I roll back?
You rarely have to. A version that does not answer /up never gets traffic, so a broken deploy changes nothing. For the rest, deploy the commit you want. Git is the rollback.
When do I need a second server?
Later than you think. The next app goes on the same box, with its own domain and its own backups. The CLI talks to one server today, and that is on purpose: one machine to think about.
What is underneath?
Boring, proven parts. Docker runs the apps. kamal-proxy, from 37signals' Kamal, does HTTPS and the swap. Let's Encrypt signs the certificates. Litestream streams the database to your bucket. Chasen is the small tool that holds them.
[08] who
~ $ finger karloscodes
Plan:
I run my own products on single servers with SQLite. I wanted the deploy of a platform without the platform.
A chasen is the bamboo whisk that prepares matcha. Matcha is the engine that runs my servers. Chasen is the tool you hold.