Hatchik
The technical details
Last updated 13 September 2026.
Everything specific about Hatchik, on one page: what a project runs on, every number, how drafts and undo work, backups, the download, and what Hatchik does not do. Nothing here is something you have to understand to use Hatchik — it is here so you can check before you commit.
On this page
What every project includes
- Hosting — your project runs on Hetzner Cloud in Germany, each one in its own isolated container with its own memory, processor and disk limits.
- A secure web address — a free
yourproject.hatchik.comwith HTTPS set up and renewed automatically. - Your own domain — point a domain you own at your project, as many as you like, with the certificate issued and renewed for you. Your AI walks you through the one DNS record it needs. Buying a domain from inside the chat is not available yet.
- A Postgres database (apps) — a real database of its own, created the moment your app needs to store something.
- A draft address and a live address — every change goes to the draft first.
- Ten saved versions — code and data together, restorable by name.
- Nightly backups, encrypted, held on a second provider in another country.
- A contact form that emails you, on free websites and paid apps alike.
- AI features inside your app — add your own AI provider's key and your app can use it for whatever you build: a chatbot, smart search, reading a photo.
A free website is files being served — pages, pictures, styling, and a contact form. It has no database, so it cannot have sign-ups, accounts, a shop or bookings, and its preview link lasts 24 hours rather than living at a permanent draft address. Everything else is the same as a paid app.
The numbers
Every limit Hatchik has is in this table. There is no unwritten fair-use line behind it, and nothing here needs asking for.
| What | The limit | What happens if you reach it |
|---|---|---|
| Room for files | 10 GB app 2 GB website |
Pages, pictures and anything your customers upload. Your app can no longer save anything new, and you are told well before it happens. A brochure site with photographs is usually 20–130 MB. |
| Room for data | 5 GB | The database: accounts, orders, bookings, messages. Your app still shows everything it has but cannot save a new record. Records are small, so this holds hundreds of thousands of them. |
| Memory and processor | 1.5 GB and 1.5 cores for an app 512 MB and 0.5 cores for a website |
An app's database gets a further 512 MB and one core. If an app runs out of memory it is restarted straight away and comes back by itself, and your AI is told in those words what happened. |
| Saved versions | The last 10 published | The eleventh publish drops the oldest. You cannot go back further than ten. |
| Files inside a saved version | Up to 250 MB | Below 250 MB, a version holds your code, your data and your uploaded files together. Above it, versions hold code and data only — keeping ten copies of a very large set would fill the machine. Going back tells you at that moment that the files were left where they are. |
| One publish | 100 MB packaged 50 MB written from chat |
Refused, and it says so plainly. Your live site is not touched, because nothing is replaced until the whole thing has arrived. |
| Copying in a site you already have | 60 pages · 600 files · 250 MB · 45 seconds of fetching · 80 MB per file | You still get the site. Hatchik brings over everything it reached, publishes that, and names the pages it did not get to. |
| Contact form | 10 an hour from one visitor · 20,000 characters · 40 fields | That visitor's eleventh message in an hour is turned away and they are told. Everyone else goes through. There are also whole-site ceilings — 60 an hour and 200 a day — well above any real day, counting only messages that actually reached you. |
| Downloading everything | No size limit · link lasts 24 hours | Ask as often as you like; each ask gives a fresh link. The only refusal is if the server is short of room at that moment, and then it says so. |
| Reading what your app is doing | The last 200 lines | Older lines are not shown. For a fresh problem the cause is in the recent lines. |
| Apps on the platform | A running total | While apps are free there is a ceiling on how many exist across Hatchik at once. If it is reached, creating a new app says so plainly and says when to try again. Free websites are never counted. |
More room than a project starts with is available, and buying it is not switched on yet. Until it is, a project that genuinely outgrows its allowance has the room added for it at no charge. Nothing is ever added to a bill without you agreeing to it on a Hatchik page that shows the price first.
What is not counted
- Visitors, page views and traffic. Nothing measures how busy your site is. A good day costs you nothing and cannot take your site down.
- How often you publish. Twenty times in an afternoon is fine, and fixing the same thing five times costs the same as fixing it once.
- How many free websites you keep. Never counted, capped or billed.
- Your own web addresses. Attach as many as you like, HTTPS included and renewed.
Drafts, publishing and undo
The draft
Every change lands on a draft at its own address, and your live site carries on exactly as it was. An app's draft has its own separate database, so trying things out cannot touch your customers' records.
The draft is locked: a stranger who asks for it gets a page saying so. The lock is a key rather than a guest list — the address itself is guessable, so what protects the draft is the check, not the address. Anybody you hand the opening link to can open it and pass it on, so treat it as you would a password.
Publishing
Publishing puts live the draft you just looked at — the same files, not a fresh attempt at them. It is one step: when you say publish, it publishes, with no second confirmation.
Undo
Every publish first saves what was live: the site's files, a copy of the app's database at that moment, and your app's uploaded files, in one archive. Saying "undo" puts all of it back together, in one operation — the current state is copied aside first, and if the database restore fails the files go back too, so you never end up with yesterday's pages in front of today's records. The last ten versions are kept and any of them can be restored by name.
The database is put back to exactly what the copy holds rather than merged with what is there now. That is what makes undo actually undo a bad import — and it means going back also takes back real life: orders, accounts and messages created since that version go with it, and a whole kind of record your app started keeping since disappears with everything in it. Before touching anything, Hatchik counts what that would cost and tells you — how many records, from which part of your app, which kinds vanish outright. Where it cannot count (plenty of records carry no date), it says so, and waits for your yes either way.
Undo puts your draft or your live site back. It does not undo deleting a project, and it does not undo a web-address change.
Backups
Every site and every database is copied each night. The copies are encrypted and held with a second provider in another country. A separate check runs daily and asks the one question that matters — how old is the newest off-site copy — and raises it if the answer is more than 36 hours.
Publishing never fails because the copy before it failed, which is deliberate: a publish that fails for a backup's sake is worse. It does mean a copy can occasionally be missing, and taking a download before anything big removes the question.
The restore was proved on 12 September 2026. The whole nightly backup was restored from the off-site copy — not the copy on the machine — into an empty directory and checked. 2.7 GB came back in sixteen seconds. Every table matched the live system row for row, all three app databases came back complete, and the archive of every site's files read end to end. Nothing was missing. One thing worth recording: with the off-site store full, the ordinary restore command could not start until it was given an extra instruction, which is now written down. The drill will be re-run and re-published; one pass is a fact, not a guarantee.
Taking everything with you
One file per project, whenever you ask: the files from your draft and your live site, the database from each in two formats — the compact one and plain SQL you could open in five years with none of this software installed — your contact-form messages, your settings, and a written guide to running it elsewhere.
It runs without Hatchik, with one thing deliberately left out: the value of each key and password. They are listed by name with the value blank, because an export gets emailed and copied around and a live payment key inside one is a key loose in the world. You copy those back from whoever issued them before it runs.
A download needs the app switched on, because it takes the database out of the running app. A paused or switched-off project can produce a download with your files and not your records — and it tells you so inside the download itself. Take one while things are healthy.
Deleting a project, or the whole account, is something you do yourself, with nobody to ask.
Security
- Your database has no public address. It is on a private network with no port open to the world, and only your own project's app can reach it.
- Each project is isolated. Its own container, its own network, its own hard memory, processor and disk limits, so one project going wrong cannot take another with it.
- Your app is reachable only through Hatchik's front door. The machine accepts nothing else.
- One narrow check at publish time. When a sign-in page on your own site posts a password to an address your project does not own — almost always because the page came from an example and the form action was never changed — Claude tells you, names the file and the address, and blocks nothing. That is one check on one thing. It is not a security review, and nothing on Hatchik is: nobody here reads your code or your database.
- It is one machine, and there is no uptime promise. The isolation above is the ordinary kind, on one shared machine. Hatchik publishes no uptime figure because it has not earned one. The status page shows what is measured.
The connector
Hatchik connects to Claude as a custom connector — nothing is installed on your computer and your password is never shared. The address is https://app.hatchik.com/mcp, and you sign in with Google once. You can switch the connection off at any time from your Hatchik account or from your AI tool's settings.
Anything that speaks the same connector standard should work; Claude is the one that is tested. Adding it by hand, in Cursor or elsewhere.
If you would rather your AI read the deploy contract itself — the Dockerfile, the port, the health check, the database address — it is written for exactly that at how apps run on Hatchik.
What Hatchik does not do
- No AI of its own. You keep yours. Hatchik cannot build anything for you.
- No sign-in service. Your AI writes sign-up and password-reset code that lives in your own app and your own database, which is more portable and more work than a hosted login page.
- No payments built in. Taking money from your customers is your app's job, with your own payment company. Hatchik hosts the app that does it and is never in the middle of it.
- No way to bring an existing database in. You can take everything out at any time; there is no import.
- Claude, and anything else that speaks the same connector standard. Not ChatGPT, today.
Home · How it works · Pricing · Help · Add Hatchik to Claude