Back to ogschaut

GitHub deployment platform

GitHub deployment with a reviewable preview before production

A GitHub deployment on ogschaut starts with a signed push or pull request. The exact commit is built in isolation, stored as an immutable image digest and published as a preview. Production receives that reviewed digest without a hidden rebuild.

Connect GitHub Compare alternatives

From GitHub event to production route

The source credential exists only during checkout. Build and runtime remain separate trust boundaries.

  1. 1

    Verify GitHub

    The GitHub App installation, repository identity, webhook signature, ref and commit are checked before work is queued.

  2. 2

    Build the exact commit

    A rootless BuildKit worker receives a short-lived installation token and bounded build variables. It pushes only an immutable image digest.

  3. 3

    Publish an independent preview

    Each preview gets its own workload and URL. Readiness must pass before the route is returned to the pull request.

  4. 4

    Promote in order

    Production traffic moves only to the greatest accepted release sequence. A slow older build cannot replace a newer release.

  5. 5

    Rollback without rebuilding

    A known image digest becomes a new ordered production release. The previous workload remains stopped and recoverable.

Supported source

GitHub App repositories and signed push or pull-request events

Supported builds

Dockerfile, Node, Next.js and static; adapter-based projects with a production start command

Runtime contract

Non-root container, port 8080, readiness before traffic and explicit CPU/memory limits

GitHub deployment questions

Does production rebuild the repository? No. Production receives the immutable image digest created by the deployment. A rollback also reuses a stored digest.
Can several pull-request previews run together? Yes. Preview workloads and hosts are deployment-specific. Production release ordering does not collapse independent previews.
Are GitHub tokens stored in deployments? No. A short-lived installation token is requested for one checkout and never persisted in the deployment, build result or runtime payload.