How SleepingFire runs four services on Abasthan

Most "deployed on X" posts show one static site. This one is four separate services — a marketing site, an admin panel, a merchant-facing web app and a Python API — each with its own custom domain, each redeployed automatically on every push, running on Abasthan right now.

SleepingFire is point-of-sale and inventory software for small merchants who don't run a fixed storefront — pop-ups, food trucks, boutiques and market stalls. It's a good stress test for a PaaS precisely because it isn't one app: it's a small constellation of services that all have to deploy independently, talk to each other reliably, and stay up without anyone babysitting them.

Disclosure: SleepingFire is built and run by Abasthan's own team, so we have direct access to how it's actually deployed — which is also why we can be specific below instead of vague.

Four services, one account

Here's what's actually running, each as its own app on Abasthan, each auto-deploying from its own private GitHub repository on every push to its branch:

• sleepingfire.com — the marketing site, a Next.js app on Node.js 22.
• admin.sleepingfire.com — the internal admin panel, also Next.js on Node.js 22, deployed as its own service so an admin-panel redeploy never touches the marketing site.
• app.sleepingfire.com — the merchant-facing web app, a React single-page app built with npm install && npm run build and served as a static site.
• api.sleepingfire.com — the backend API, a Python 3.12 service (FastAPI) that every other piece calls.

Each one is a plain web service or static site in Abasthan terms — nothing custom-built for this. The only platform feature that makes "four independent services under one brand" work cleanly is that every app gets its own free custom domain with automatic SSL, so each piece can live on its own subdomain instead of everything being crammed onto one app with internal routing.

Cloudflare in front, Abasthan behind

SleepingFire puts Cloudflare in front of all four domains for HTTPS and redirect handling — every response carries Cloudflare's headers at the edge, with Abasthan's own ingress serving the actual request behind it. That split is deliberate: Cloudflare handles the edge concerns (TLS termination, redirects, DDoS absorption) it's built for, and Abasthan handles running the actual containers, so neither layer is doing the other's job.

Deploys, and a health check that answers two ways

Deploys are the plain Abasthan flow: push to the branch, Abasthan builds the image, and the new version is live — Node.js builds via npm install && npm run build, the Python API via pip install -r requirements.txt. No manual steps on any of the four services.

The API exposes a /health endpoint used for uptime monitoring that does a real database round trip, not a hardcoded "ok":

$ curl .../health
{"status":"ok","database":"ok","database_ms":44.0}

The lesson that cost SleepingFire an hour of confusing false alerts early on: some uptime monitors probe with HEAD instead of GET to save bandwidth. A health endpoint that only handles GET will 405 on those checks and look down when it isn't. /health now answers both — worth checking on any health endpoint you point a monitor at, on any platform.

Why this is a reasonable way to run four services

None of this needed Kubernetes YAML, a service mesh, or someone on call for infrastructure. It needed four git repos, four Abasthan apps, and four DNS records. Specifically, what the platform did for each service without extra setup:

1. Isolation that matters: a bad admin-panel deploy can't take down the storefront or the API — they're separate apps with separate build pipelines and separate rollback histories.
2. No infrastructure bill before the first customer: the first app on any account is free, so the early services ran at $0 while SleepingFire was still finding product-market fit.
3. Billed for what actually runs: per-second billing on prepaid credits means none of the four services costs more than the plan price, and nothing runs up a bill while idle.
4. Debuggable without SSH gymnastics: live build and runtime logs, environment variables and secrets managed per app, and SSH or an in-browser terminal into any of the four when something needs a closer look.

If you want the free tools SleepingFire built for merchants along the way — a barcode generator, a time-card calculator, an invoice generator and a few others — they're at SleepingFire's free tools, and they run on the same four-service setup described above.