open source · for apps on SQLite · on your own server
One command. It's live.
Chasen puts your Dockerfile app on one server, with its data in SQLite. HTTPS, zero-downtime deploys, and backups come built in.
chasen example.com 3 apps ──────────────────────────────────────────────────────────────────────────────────────────────────────────────── apps │ overview history backups domains logs $ chasen -a shop status │ ● blog │ shop ● Up 3 hours (healthy) ● lognorth │ ▸ ● shop │ Version 3f9a2c1 │ URL https://shop.example.com │ https://shop.com │ Backup Oct 2 10:00 UTC · 19 min ago │ Replica live │ │ Last changes │ 4 Oct 2 07:19 · 3 h ago deploy 3f9a2c1 ✓ succeeded │ 3 Oct 2 05:19 · 5 h ago deploy 6cff7df ✗ failed │ 2 Oct 1 09:19 · 25 h ago domains add shop.com ✓ succeeded server │ 1 Oct 1 08:19 · 26 h ago deploy 727846a ✓ succeeded load ━─────── 0.50 │ mem ━━────── 31% │ disk ━━━───── 41% │ │ █ █ █ █ █ █ █ │ █ ▀▄ █ █ █ ▄▀ █ │ █ █ █ █ █ █ █ │ █ █ █ █ █ █ █ │ ▀ █▄█▄█▄█▄█ ▀ │ ▀▀███▀▀ │ ███ │ ──────────────────────────────────────────────────────────────────────────────────────────────────────────────── ↑↓ app → its overview tab next tab r restart b backup o open : command ? keys q close
chasen with no command: the screen of your server. Its load, and the state, history, backups, domains, and logs of each app.
[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] install
Free. On your own server.
Chasen is open source, and the open source version is the whole product. We add one program to your server, chasen-server. The rest of the server is yours to run.
curl -fsSL https://chasenhq.com/server | sh
chasen-server setup --domain example.com
# setup prints the token of the server. Keep it.
# optional: a bucket, for backups that outlive the server
chasen-server bucket --endpoint ... --name backups
curl -fsSL https://chasenhq.com/cli | sh
chasen add server example.com
# opens a page. Type the token of the server.
# the git origin of the app is on GitHub
docker login ghcr.io
chasen deploy
Building ghcr.io/you/shop:3f9a2c1d5e8b7a6094c3f2e1d0b9a8c7d6e5f4a3
Pushing ghcr.io/you/shop:3f9a2c1d5e8b7a6094c3f2e1d0b9a8c7d6e5f4a3
Pulling ghcr.io/you/shop:3f9a2c1d5e8b7a6094c3f2e1d0b9a8c7d6e5f4a3
Port 3000 (EXPOSE in the image). Health path /up. Storage /storage.
shop: backup 20261001T120000Z (on the server and offsite)
Starting shop 3f9a2c1
Deployed shop 3f9a2c1
https://shop.example.com
You need a server with Ubuntu or Debian, ports 80 and 443 open, and a wildcard DNS record for *.example.com. On your computer you need Docker, git, and an account at ghcr.io or Docker Hub. Get started, step by step →
In Chasen cloud we do everything for you: the server, its hardening, its updates, and its backups. You run two commands.
chasen login
chasen deploy
€9 a month for your account, plus each server at Hetzner's price.
Join the waitlist[03] what ships
If it has a Dockerfile, it ships.
Backend services, full-stack apps, and frontend repos deploy the same way: chasen deploy builds the image, pushes it, and puts it live. Each one gets its own domain and its own HTTPS certificate.
- These four rules cover most apps. Each has a default you can change in
chasen.yml. The full standard has ten → - Nothing builds on your server. The image goes to ghcr.io or Docker Hub, and the server pulls it, private images too. A build never takes memory from your live apps.
- Logs, analytics, and forms run next to your app, with the same backups:
chasen enable lognorth, one command each.
[04] how it works
Two programs. One server. Yours.
chasen is the CLI on your computer. chasen-server is one binary on your server. They talk over HTTPS. You bring two things, and both are yours: a registry for your images and a bucket for your backups.
- 1your computerchasen deploy says which commit to deploy, and sends chasen.yml and the secrets over HTTPS, with a token. No SSH.
- 2your registryghcr.io or Docker Hub. Your computer or your CI pushes the image of each commit there. Nothing builds on the server.
- 3proxykamal-proxy, with Let's Encrypt certificates. It sends each domain to its container.
- 4chasen-serverThe API. It pulls your image, asks /up, swaps the version, and backs up every database.
- 5your appsOne container each, with its SQLite files in /storage. Visitors reach them through the proxy.
- 6your bucketEach hour a checked snapshot, each second the new changes. A new server gets its data back from here.
- The server needs Docker and nothing else. A deploy step by step, the protocol, and the files on the server →
[05] 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.
- The server can die.
- Set up a new one with the same bucket and run chasen deploy. The data comes back first.
[06] questions
What Chasen leaves out.
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, and a backup is a copy of that file. It is fast, too: a query never leaves the machine. Most apps never outgrow it. If yours does, you have the revenue to pick what comes next. Need Postgres today? Your app can use one that runs elsewhere.
What happens when the server dies?
You set up a new server with the same bucket, point your DNS at it, and run chasen deploy for each app. The data comes back first, about one second old. Then you add your custom domains again. That is an hour of work on a bad day, in exchange for no failover cluster to operate on every other day. When you are starting a business, it is a risk you can afford.
How do I roll back?
A version that does not answer /up never gets traffic. To go back to an older version, run chasen deploy --tag with the hash of its commit: the image is still in your registry, so nothing builds. If the bad version changed the database, chasen restore returns the backup that Chasen made before that deploy.
What are the limits?
One container for each app, with 512 MB of memory, and no worker process yet. SQLite only. Uploaded files persist across deploys, but they have no backup yet. The build is for amd64 servers; an ARM server needs one environment variable.
How is this different from Kamal?
Kamal is the closest relative, and Chasen runs on its proxy. Kamal does more: several servers, any database, any setup you can write down. If that is what you have, use Kamal. Chasen does less on purpose, one server with SQLite, and that buys you three things. No SSH: the deploy goes to an HTTPS API with a token, so no laptop and no CI job holds a key to your server. No backup homework: every SQLite database is copied each hour and streamed to your bucket each second, and a restore is one command. And no shopping for the rest: logs, analytics, and forms are one command each.
[07] 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 bug in Chasen ruins my day before it ruins yours.
A chasen is the bamboo whisk that prepares matcha. Matcha is the engine that runs my servers. Chasen is the tool you hold.
One server is plenty for the rest of us.
Chasen is free and open source. Install the CLI, add your server, and run chasen deploy.
$ curl -fsSL https://chasenhq.com/cli | sh