What MIOSA built for ClinicIQ, why it took longer than a normal app build, what is live now, what alternatives like E2B, Modal, Vercel, Fly, Railway, Render, and Cloudflare can and cannot replace, and what "V1 ready" honestly means.
Executive summary
ClinicIQ is receiving a white-labeled application infrastructure layer: users can create AI-generated apps, preview them live, publish them, serve them under ClinicIQ-branded domains, and run both static and full-stack applications.
The platform serves static and dynamic/full-stack apps on ClinicIQ domains. The dynamic runtime layer is now always-on plus self-healing — designed to recover from dead runtimes automatically. It is not yet a zero-downtime enterprise HA system, but it is ready for a controlled V1 launch.
1 · What was built
A ClinicIQ customer should not feel like they are using MIOSA. They should feel like they are using ClinicIQ's own application builder and hosting layer.
| Capability | What ClinicIQ gets | Status |
|---|---|---|
| White-label domains | Apps serve at ClinicIQ hostnames like <app>.cliniciq.com — end users see ClinicIQ, not MIOSA. | LIVE |
| Live preview | Open a preview URL while the app is being edited or booted — core to the AI builder experience. | LIVE |
| Static publishing | Frontend/static artifacts published durably without a runtime VM — best for landing pages and tools. | LIVE |
| Dynamic / full-stack | Apps with backend servers run behind ClinicIQ domains — APIs, server state, backend logic. | LIVE |
| Always-on runtimes | Production dynamic runtimes aren't treated like short-lived edit sandboxes — no idle-death. | LIVE |
| Self-healing monitor | Dead dynamic runtimes are detected and marked for replacement — no silent stale "running" state. | LIVE |
| Size-aware warm pool | Warm sandboxes assigned only when their memory tier fits — no large app in a small VM. | LIVE |
| ClinicIQ branding controls | MIOSA branding hidden/controlled by tenant settings — a real white-label experience. | LIVE |
2 · Visual walkthrough
The customer sees a clean ClinicIQ product. MIOSA stays behind the curtain and runs the infrastructure that makes the builder and hosting system work.
Hidden work per step: tenant lookup → sandbox isolation → artifact storage → runtime choice → Caddy/TLS → proxy routing → health monitoring.
Publish decision tree
Failure & recovery
A production dynamic app should not silently stay dead because a database row still says "running."
Result: an app may have a short recovery window, but it should not stay dead silently. That's the difference between V1 self-healing and a fragile demo.
4 · Why this took time
A normal launch is one codebase, one hosting target, one domain. ClinicIQ's white-label launch required building the platform that creates, hosts, routes, monitors, and recovers other people's apps.
<app>.cliniciq.com must resolve to the right tenant → right deployment → static artifact or live runtime VM. Host resolution, Caddy, DNS/TLS, and the proxy all had to agree.
An edit sandbox can be temporary; a deployed app cannot. We split the live preview from the durable publish path so users edit safely, then publish durably.
Static serves from artifacts; dynamic needs a running process, reachable IP:port, runtime metadata, health checks, and recovery — without the user knowing the difference.
Deploy metadata held both the source sandbox ID and the runtime endpoint. The source sandbox is destroyed after publish; routing to it errored. Fix: prefer metadata.runtime.ip:port.
Dynamic runtimes need the built artifact copied to the runtime host. The old SSH path couldn't use the fleet key; replaced with explicit OpenSSH/SCP with the correct identity.
Some rows said "running" while the VM was gone. Added a runtime health monitor so dead/stuck runtimes are marked terminal and the reconciler replaces them.
Hot-loading during debugging can make code look fixed without being durable. We moved to clean release deploys from exact commits so the running system matches the code.
9 · Dynamic runtime lifecycle
| Failure case | Before the fix | After the fix |
|---|---|---|
| Runtime VM dies | DB could say running while the app returned errors. | Monitor marks runtime error; reconciler starts a replacement. |
| Stuck starting, no IP | Blocked replacement because it looked active. | Stale starting/provisioning rows detected and marked error. |
| Fleet restart | Some proof apps lost their runtime and didn't recover cleanly. | Monitor + reconciliation replace dead targets. |
| Caddy upstream ambiguity | localhost:8091 could fail at the edge path. | Routes use 127.0.0.1:8091 for stable IPv4 loopback. |
11 · Current proof
# live checks performed 2026-06-01 against the current release api.miosa.ai/health 200 {"status":"ok","service":"miosa-compute"} app-pomodoro.cliniciq.com 200 static · verified dyn84265.cliniciq.com 200 DYNAMIC LIVE RuntimeHealthMonitor running monitor_check marked_error: 0 · tracking_failures: 0 service active · NRestarts=0
Honest reliability wording: this is self-healing always-on infrastructure, not yet multi-replica zero-downtime HA. If a dynamic runtime dies, the monitor and reconciler replace it; during replacement there can be a short visible recovery window. Static apps have no VM runtime risk.
16 · V1 readiness decision
| Launch promise | Can we say it? | Notes |
|---|---|---|
| Users can create and preview apps | YES | Live preview + sandbox path available |
| Publish static apps on ClinicIQ domains | YES | Verified — app-pomodoro.cliniciq.com |
| Publish full-stack apps on ClinicIQ domains | YES | Verified — dyn84265.cliniciq.com |
| Dynamic apps stay running 24/7 | YES | Always-on + health monitor + reconciler |
| Zero downtime under every failure | NOT YET | Requires multi-replica / faster failover |
| Provider-independent long term | YES | MIOSA stays the control plane; see providers → |
17 · Client-friendly explanation
"We were not just building a website. We were building the infrastructure that lets your users generate, preview, publish, and host their own applications under your brand. That required domain routing, TLS, live preview, static hosting, dynamic app hosting, sandbox isolation, runtime monitoring, and recovery. It took longer because the platform has to keep working after restarts, deployments, and runtime failures — not just work once in a demo."
"The V1 platform is now launchable. Static apps are durable. Full-stack apps run through an always-on runtime path with health monitoring and self-healing. The next reliability upgrade is multi-replica zero-downtime failover — a higher availability tier, not a blocker for V1."
18 · Next steps after V1
Security note: this report intentionally excludes API keys, tenant secrets, SSH key material, database credentials, and private environment values. It explains architecture and readiness without exposing operational secrets.