Skip to main content
apowerb-hosting holds no application code. It assembles apowerb/apowerb (the API) and apowerb/apowerb-ui (the interface) and gives them a database.

​
Deployment options

apowerb-hosting repository provides the following deployment assets for the stack:
  • Docker Compose: Uses published images from Docker Hub.
  • Kubernetes: Static manifests.
  • Helm: Local source tree chart.
  • Single VM / HTTPS with Traefik: Overlay Traefik HTTPS configuration.
See the GitHub repository for full configuration details and scripts.

​
Images are pulled, not built

The compose file references published images, pinned to explicit versions — there is no build: block and no sibling clone to fetch. The pinning is deliberate. A moving tag such as latest promises nothing about the API and the interface having been tested together; the pair declared in the file was proven together — sign-up, sign-in, an agent created and read back. Override both tags when you move, never one alone: the frontend and the backend cap each other in both directions. No system packages are installed in the images: psycopg2-binary, asyncpg and cryptography arrive as prebuilt wheels, and the health probes are written in Python and Node rather than shelling out to curl. The build therefore depends on no Debian mirror.

​
Published assets

​
Helm chart OCI registry

The chart moved out of apowerb/apowerb in 0.4.1. That repository holds the backend images, and a Docker Hub repository cannot be subdivided, so the two artefacts shared one tag namespace: apowerb/apowerb:0.4.0 was a 16 kB chart, :0.2.12 a 250 MB image. Charts published before the move are still pullable at the old address; new ones are not.GitHub Container Registry was dropped the same day. The push succeeded, but a package is born private in a GitHub organization, so a helm pull from ghcr.io answered 403 to anonymous users.