App hosting

• A container image is built from the code, with build logs streaming while it runs.
• Redeploy on demand, or cancel a build that is already running.
• Every app keeps a full deployment history: each build, when it went live, and how it ended.
• Releases are zero downtime. The running version keeps serving until the new one passes its health check.

Apps are web services by default. They serve HTTP, get a URL, and each release waits for a health check before traffic moves to it.

Some code never serves HTTP: a Telegram bot polling for updates, a queue consumer, a scheduled job runner. Setting the service type to worker runs it with no public route and no HTTP health check. A worker has no URL and no path prefix, and that is the design rather than a limitation to work around.

• Start, stop and restart apps from the console.
• Set and update environment variables per app. Changes apply on the next deploy or restart.
• Stream runtime logs live, or take a snapshot of recent lines.
• Group services into projects, and mark each by type: web, API, worker, database, cache or queue.
• A failed deployment sends an SMS and an email rather than leaving the failure silent.

• Every app gets a free aletcloud.com subdomain, checked for availability as it is chosen.
• A custom domain can be added once ownership is proven, after which certificates are issued and renewed automatically.
• Path routing puts several apps under one domain, such as yourdomain.com/api and yourdomain.com/shop.

• A plan sets how many apps the account can run, the CPU and RAM per app, the replicas per app, and the build minutes a month.
• Solo is free: one app per account, for life, on one replica and the same pipeline the paid plans use. It carries no expiry date and no persistent disk.
• A free app sleeps after a spell without traffic and wakes on the next request. That first request is slower than the rest, and it is not an error.
• A paid app is charged by the minute against its monthly price. Creating one checks the wallet for a day of it first.

A container’s filesystem is replaced on every release, so anything that has to persist belongs in object storage. Create a bucket, connect it to the app in one action, and the S3 environment variables are injected for you.