Cicatrixa — AI-operated hosting. Push a repo, get a healed, hosted app.

booting

Point Cicatrixa at a GitHub repo — or several. The AI works out how to build it, wires a subdomain, verifies the deploy actually works, and stays on call: every push redeploys, every crash gets diagnosed and repaired, before you ever hear about it.

Deploy your first repo → Log in

▼ HOW IT REFUSES TO GUESS

YOU BRING a GitHub repoor several CICATRIXA SHIPS a live subdomaina verified deploya watchdog on call

The objection, answered

You could SSH in and
docker build it yourself.

Sure. Nobody does, because the work isn't the build — it's everything around it. Cicatrixa is the ops engineer that does the part you'd rather not: the Dockerfile nobody wrote, the port that only your app knows, the crash that happens while you're asleep.

No verified deploy, no traffic. Ever.

— THE ONE RULE THE ROUTER CANNOT BREAK

The healing loop

Six stages. Each one gated by the last.

The same bar you'd hold a careful engineer to — proof before promotion, every single deploy.

  1. 01Connect

    GitHub App in one click, or a token in thirty seconds. Pick one repo or several — frontend, backend, workers.

  2. 02Analyze

    The AI reads the repository like a chart: framework, entry point, port. No Dockerfile? It writes one.

  3. 03Build & route

    Containers build on a sealed internal network — no host ports, ever — and a subdomain wires itself.

  4. 04Verify

    Nothing takes traffic unproven. The deploy is smoke-tested and the AI signs off on the result in writing. Build or boot fails? It diagnoses the log and retries — up to three times — before you'd ever notice.

  5. 05Heal

    Every push redeploys in seconds. Crashed containers restart themselves; chronic failures rebuild from source. The previous version keeps serving until the new one proves healthy.

  6. 06Consult

    Talk to it. "Check the API for errors" — it investigates the real logs and code, proposes an exact patch, and — only once you approve — commits, pushes to your GitHub, and redeploys.

The product, live

Watch a real deploy heal itself.

This is the control plane your team sees — an actual run, stage by stage, from a bare repo to a verified, self-healing service.

cicatrixa · control plane — attest-backend (production) LIVE
connectanalyzebuild & routeverifyhealconsult

Get running

Two clicks to connected,
one push to deployed.

Sign up, connect GitHub, and pick a repo — or a whole project's worth. There's nothing to install; the build happens on our side, not yours.

STEP 1

Sign up

Email and a password. No credit card, no waitlist — you're in the dashboard in under a minute.

STEP 2

Connect GitHub — two clicks

The GitHub App's own repo picker grants access to exactly what you choose. A token works too.

STEP 3

Deploy

Pick a repo (or several for one project) and watch the log — live at your-project.cicatrixa.com in minutes.

# a single service — the AI writes the Dockerfile itself [09:00:21] ⇣ cloning you/orders-api@main [09:00:23] 🧠 analyzing repository (AI) [09:00:29] plan: FastAPI service, gunicorn workers (port 8000) [09:00:29] 🔨 build attempt 1/3 [09:01:40] 🚀 starting container — expecting port 8000 [09:01:46] ✓ HTTP 200 on port 8000/ [09:01:47] 🧪 smoke test: HTTP 200 · 🧠 AI verdict: healthy [09:01:47] ✔ deploy complete — orders-api.cicatrixa.com

Where we sit

A VPS gives you a shell.
A typical PaaS gives you a build. We give you a doctor.

roll your own VPS typical PaaS cicatrixa
Detects the right Dockerfile you write it± buildpacks only AI reads the code
Wires multiple repos together your CORS bugs same-origin bridge
Retries a failed build fails, you fix AI diagnoses & retries
Watches for crashes after deploy± restarts only restart → rebuild
Redeploys automatically on push
Chat a fix straight into a real commit reviewed, then pushed

What a chat turns into

Every fix arrives as a real commit,
not a suggestion.

This is an actual exchange: ask for an error check, get back a proposed patch with a diff — approve it, and it's built, verified, pushed to your GitHub, and live.

✓ verified, ready to pushUpdate homepage greeting to Cicatrixa
Cicatrixa Agent → flask-hello-world · +1 −1 · build re-verified before push
@@ app.py @@
- return 'Hello, World!'
+ return 'Hello from Cicatrixa!'
✓ patched code verified to build — before touching your repo ✓ committed as Cicatrixa Agent & pushed to main ✓ redeployed and smoke-tested — live in under a minute

Pricing

Three dollars a month.
An SRE that never sleeps.

One plan, everything included. Cheaper than the cheapest dyno you've ever rented — except this one notices when your app dies, and fixes it.

$2.99 / project / month
0.25 vCPU · 1 GB RAM · 5 GB storage
  • Your own subdomain with automatic HTTPS
  • AI build engine — no Dockerfile, no config
  • One-click Postgres, wired in as DATABASE_URL
  • Crash watchdog: restart → rebuild, on its own
  • AI medic: verified fixes committed to your GitHub
  • Multi-repo projects with a same-origin /api bridge
Deploy your first repo →

Invite-only while we scale the fleet — request access and we'll wave you in.

Questions, answered straight

The things you'd ask before
connecting your GitHub.

Does my code leave GitHub?

We read your repo through the exact scope you grant (GitHub App repo picker, or a token you control). Builds happen on the server hosting your app — nothing is used to train models, and nothing is sent anywhere else.

What if there's no Dockerfile?

The AI reads your stack — Node, Python, Go, static — and writes one. If the AI is unavailable, deterministic heuristics per-language cover the same ground.

What happens when a build fails?

The AI reads the failure, diagnoses the cause, and retries with a corrected plan — up to three attempts. If it truly can't, the previous working version keeps serving; nothing goes dark.

Can the chat push to my repo without asking?

No. Every fix shows up as a diff you review. Only when you click Apply does it clone, patch, verify the build, commit as Cicatrixa Agent, and push.

How do you stop one account from hogging the server?

Per-account quotas — service count, RAM, storage — enforced before every deploy, and every container is hard-capped regardless. One tenant can't starve another.

What ports do I need to open?

None. Zero. Every app runs on a sealed internal network and routes purely by subdomain — port conflicts aren't a category of bug you can have here.

Start now

Stop being your own
on-call engineer.

Sign up, connect GitHub, and deploy something real in the next five minutes. $2.99 a month once you love it — just an invite to start.

Deploy your first repo →

Contact

Talk to a human.

Questions, pilots, or something broke that shouldn't have — one address reaches the founders directly.

General & pilots hello@cicatrixa.com

We reply within one business day.

Get started Create an account →

Live in minutes, not a waitlist.