alawadi.cloudDocs
Core Concepts

App runtime model

How alawadi.cloud runs your container apps in isolated, fully managed environments, with no servers, SSH, or kubectl to manage.

Managed container runtime

Your app runs from a container image you build. You push that image via GitHub Actions (OIDC trust) or directly to your private registry, then deploy. There are no servers, SSH, kubectl, or host access to manage.

Every app you deploy gets:

  • A *.alawadi.cloud subdomain with managed TLS.
  • Live logs and metrics.
  • Start, stop, restart, and scale controls.
  • Optional custom domains.

Each app runs in its own isolated environment. You never receive SSH, kubectl, a Docker socket, privileged containers, or host access. The platform applies resource limits and isolation before your app starts.

Runtime requirements

The platform standardizes how it runs every image, so your container must follow a few rules:

  • Listen on port 8080. The platform always routes traffic to 8080. Bind your server to 0.0.0.0 and read the PORT environment variable. The starter templates in the dashboard already set this for each stack (Node, Next.js, Python, Go, PHP, Java, Rust, static).
  • Run as a non-root user. Images run under a restricted security policy, so the container must not need root. The per-stack Dockerfiles the dashboard gives you already add a non-root user and EXPOSE 8080.
  • Deploy an immutable image. Deployed images must come from your registry.alawadi.cloud registry with an immutable tag or @sha256: digest. :latest and untagged images are rejected. Deploy workflows use the commit SHA as the tag automatically.

Until your first deploy, a new container boots a placeholder image so the app and its domain are live immediately. Your real image takes over on the first successful deploy.

Not VPS

Managed App Hosting is a PaaS / container product. VPS and root access are future products with a separate isolation design.

On this page