open source · for apps on SQLite, and frontends · on your own server
One command. It's live.
Deploy and manage your servers from your terminal. Your app or frontend, on a server you own: HTTPS, zero-downtime deploys, and SQLite replicated to S3-compatible storage.
chasen example.com ! 2 warnings 3 apps ──────────────────────────────────────────────────────────────────────────────────────────────────────────────── servers │ overview history backups domains logs $ chasen -a shop status │ example.com │ shop ● Up 3 hours (healthy) ● blog │ ● lognorth │ Version 3f9a2c1 ▸ ● shop │ URL https://shop.example.com example.org │ https://shop.com ○ shop │ Backup Oct 2 10:00 UTC · 19 min ago │ Replica live │ Disk data 1.2 MB · backups 840 KB in 6 · image 87.4 MB │ │ Last changes │ 4 Oct 2 07:19 · 3 h ago deploy 3f9a2c1 ✓ succeeded 38s │ 3 Oct 2 05:19 · 5 h ago deploy 6cff7df ✗ failed 38s server │ 2 Oct 1 09:19 · 25 h ago domains add shop.com ✓ succeeded 2s load ━─────── 0.25 │ 1 Oct 1 08:19 · 26 h ago deploy 727846a ✓ succeeded 38s mem ━━────── 28% │ disk ━━━───── 41% │ │ █ █ █ █ █ █ █ │ █ ▀▄ █ █ █ ▄▀ █ │ █ █ █ █ █ █ █ │ █ █ █ █ █ █ █ │ ▀ █▄█▄█▄█▄█ ▀ │ ▀▀███▀▀ │ ███ │ ──────────────────────────────────────────────────────────────────────────────────────────────────────────────── ↑↓ app : command t theme r restart b backup o open → its overview ? keys q close
chasen: the screen of your server
1 / 16chasen with no command: the screen of your server. Every key does what a command of the CLI does.
[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/cli | sh
chasen deploy --server root@203.0.113.5 --domain shop.example.com
chasen-server is not on this server yet. Installing it.
Setting up the server.
Installing Docker. This takes a minute or two.
Starting the proxy.
Starting the API.
The server is ready.
Logged in to ssh://root@203.0.113.5
Starting the registry of chasen on this computer. The image goes from here to the server, through SSH.
Building shop 3f9a2c1
Pulling the image from your computer, through SSH
Port 3000 (EXPOSE in the image). Health path /up. Storage /storage.
Starting shop 3f9a2c1
Deployed shop 3f9a2c1
https://shop.example.com
✓ https://shop.example.com answers from here.
chasen deploy
# the computer knows the server, and the app has its domain.
# optional: a bucket, for backups that outlive the server
chasen bucket --endpoint ... --name backups
You need a server with Ubuntu or Debian that you reach with SSH, with ports 80 and 443 open, and a DNS record for the domain of your app. On your computer you need Docker and git. A registry like ghcr.io or Docker Hub works too, when you want one: for CI, or for an image you did not build. 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, sends it to the server, 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, and no registry is needed. The image goes from your computer to the server through SSH. A build never takes memory from your live apps.
chasenon your computer talks to one program on the server,chasen-server. How it works → ghcr.io, Docker Hub, and other registries work too, private images as well. - An app that someone else made deploys from its image, with one line:
chasen deploy ghcr.io/acme/chat --domain chat.example.com. Add--auto-update, and the server deploys its newest image each night. Logs, analytics, and forms run next to your app the same way:chasen enable lognorth.
[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 1.4 MB 20261001T110000Z server + offsite 1.4 MB 20261001T100000Z server + offsite 1.3 MB 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. A restore from the bucket misses about the last second of writes, not the last hour.
- Checked.
- A copy that fails the integrity check is not a backup. A failed backup stops the deploy.
[05] 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. And your app can still connect to another database if you want one.
How do I roll back?
A version that does not answer /up never gets traffic. To go back to the version before, run chasen rollback: the server kept its image, so it takes seconds. 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 unless you give it more, plus one jobs container when you ask for it. SQLite only. Uploaded files persist across deploys, but they have no backup yet.
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 setup step: the first chasen deploy puts Chasen on the server, through SSH, and after that a CI job can deploy with a token, so it holds no 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.
[06] 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