Connect a container registry

Create a private registry on alawadi.cloud, push images from GitHub Actions over OIDC, and deploy them to a container.

Every app on alawadi.cloud runs from a container image you push to a private registry at registry.alawadi.cloud. You create the registry in the dashboard, grant a GitHub repository permission to push over OIDC (no static passwords), then deploy the image to a container. This page walks the portal-first flow end to end.

1. Create a registry

Open Dashboard → Registries (/dashboard/registries) and click Create registry. Fill the dialog:

Name (required). For example Production apps.

Slug (optional). It is derived from the name automatically and shown live in the address preview. Override it only if you want a different path. The slug is immutable after creation.

Project (optional). Link the registry to the project that will run its images. Defaults to Link later; you can link or change it afterward.

Storage (GiB): image storage quota (default 1, range 1-100).

Click Create. The platform assigns the rest for you:

The Address and Image namespace at registry.alawadi.cloud/<tenant>/<slug>. You never type the host or path.
The registry Status moves from provisioning to ready.

Both values appear on the registry detail page (/dashboard/registries/<id>) in the Overview card, each with a copy button. Use Edit settings there to rename, resize storage, or link a project (the slug stays fixed).

2. Grant push access (GitHub Actions OIDC)

On the registry detail page, find the Push setup (GitHub Actions OIDC) card and fill the trust form:

GitHub repository (required), in owner/repo form.

Branch ref (required). Pre-filled with refs/heads/main. It must start with refs/.

Environment (optional). Leave empty unless you use GitHub Environments. When set, your workflow job must include environment: <name>.

Click Configure trust (it becomes Update trust / Remove trust afterward). The card shows the read-only OIDC Audience the registry assigned. You never write it by hand.

No passwords, ever

Pushes authenticate with a short-lived token minted from GitHub's OIDC identity (docker login registry.alawadi.cloud -u oidc --password-stdin). There are no static registry passwords, robot accounts, or Docker Hub credentials to create or store.

The same card renders a ready .github/workflows/push.yml snippet, pre-filled with the real address, audience, and REGISTRY_ID. Click Copy and commit it if you only want to push images. Pushing alone does not deploy. For continuous deployment, use the workflow templates below.

3. Copy a deploy workflow

Scroll to the CI workflow templates card. It generates a complete .github/workflows/deploy.yml that builds your app, pushes the image here, and rolls it out to a container.

Pick your runtime. Tabs cover Node · Express, Next.js · React, Python · FastAPI, Python · Django, Go, PHP · Laravel, Java · Spring Boot, Rust, and Static · Vite. The card shows that stack's App port (always 8080), Health endpoint, and expected Env vars.

Pick a deploy target from the Deploy target dropdown. The list is your containers, filtered to the registry's linked project. If it's empty, create a container first.

Configure deploy trust. Watch the badge next to the dropdown: Deploy trust configured (green) or Deploy trust required (amber). If required, click Configure deploy trust. One click reuses the registry's repository, branch ref, and environment, so there is nothing to re-type. The badge flips to configured and the button becomes Refresh deploy trust.

Click Copy workflow. The file is fully generated for the selected container: IMAGE, PUSH_AUDIENCE, CONTAINER_ID, and DEPLOY_AUDIENCE (alawadi-deploy:container:<CONTAINER_ID>) are all filled in. The only edits it asks for are the per-stack build variables shown as inline comments (and DOCKERFILE if yours isn't at the repo root).

Paste it into .github/workflows/deploy.yml, adjust those build variables, then commit and push to main.

If your repo has no Dockerfile yet, expand Supporting Dockerfile and click Copy Dockerfile. Each one listens on 8080, runs as a non-root user, and pins its base image to a major version, ready for the platform's restricted security policy.

Two trusts are required

Push trust (step 2) lets GitHub push the image; deploy trust (step 3) lets the same repository roll it out to one container. Pushing to the registry does not deploy on its own; both trusts must be in place.

What happens on a push

When the workflow runs, it:

Logs in to registry.alawadi.cloud with an OIDC token (no password).
Builds and pushes IMAGE:<commit-sha>. It sets BUILDX_NO_DEFAULT_ATTESTATIONS=1 because the registry rejects GitHub's default build-attestation manifest.
Mints a short-lived deploy token from a second OIDC token (audience DEPLOY_AUDIENCE) and POSTs the image to your container.

Watch pushed tags appear in the Images card (it auto-refreshes with a Live indicator, where you can copy a pull reference or delete tags), and follow the rollout in the Deploy history card and on the container's timeline.

Pin image tags

The generated workflow tags images with the commit SHA, not :latest. Keep it that way: the platform rejects :latest and untagged images so a redeploy always rolls the exact image you built.

Advanced: configure trust from CI (API)

The portal forms above are the primary path. If you automate registry or trust setup from your own scripts, the same operations are available on the API. Registry push trust:

# Configure (or update) push trust for a registry
curl -sS -X PUT \
  "https://api.alawadi.cloud/v1/registries/$REGISTRY_ID/github-oidc-trust" \
  -H "Authorization: Bearer $PORTAL_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"repository":"owner/repo","ref":"refs/heads/main"}'

Container deploy trust follows the same shape. See Deploy from GitHub via OIDC for the deploy-token exchange and the per-run deploy call your workflow makes.