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.cloudsubdomain 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 to8080. Bind your server to0.0.0.0and read thePORTenvironment 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.cloudregistry with an immutable tag or@sha256:digest.:latestand 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.