Push. Ogschaut. Then live.

GitHub deployment for DACH teams: every push becomes a reviewable preview, and the exact approved image goes to production.

Built for production releases
Start deploying Understand the workflow
  • Org-scoped access
  • Signed webhooks
  • Exact usage events

bergwerk/kundenportal

Product view · example data

Preview · PR #184

Release for feature/customer-export

a81fc2d · Add encrypted export archive

Preview ready
  1. 1

    GitHub event verified

    Repository and commit are bound to the installation

    Received
  2. 2

    Deployment queued

    Preview variables and release order are fixed

    Recorded
  3. 3

    Artifact built

    Immutable image stored for this release

    Ready
  4. 4

    Preview published

    kundenportal-pr-184.preview.ogschaut.de

    Open

Example data, real product path: signed GitHub event, isolated build, immutable image and routed preview.

One release history from push to production

The preview is not a disposable side path. It is the same ordered release, with the same artifact and explicit environment boundaries.

  1. 1

    Connect the repository

    Install the GitHub App only for repositories this organisation may deploy.

  2. 2

    Create the release

    A signed push or pull request becomes an ordered deployment with scoped variables.

  3. 3

    Review the preview

    Status, URL and logs return to the pull request where the review already happens.

  4. 4

    Promote without rebuilding

    Production receives the immutable artifact that was reviewed; rollback reuses a known release.

One platform boundary from source to runtime

The control plane verifies intent, BuildKit produces an immutable artifact, and the runtime publishes it only after readiness succeeds.

GitHub in, ordered release out

Repository access is installation-scoped. Signed push and pull-request events create tenant-scoped, monotonic deployments.

Isolated BuildKit builds

Short-lived source credentials and build variables stay at the build boundary. The result is always a content-addressed image digest.

Readiness before traffic

Preview routes remain independent. Production switches only after the new workload is ready; the previous image remains available for rollback.

How GitHub deployment works Compare the Vercel alternative

Plans that match the enforced limits

Choose by team size and real monthly usage. Every plan states its build, runtime and retention limits before checkout.

Pro

For solo developers who ship real projects.

$29.00 / month

Choose plan

$24.16 / month (paid yearly)

Choose plan
  • 10 projects
  • 3 team members
  • 1,000 build minutes per month
  • 500 runtime GB-hours per month
  • 7 days of log retention

Team

Most Popular ✨

For teams that deploy together every day.

$99.00 / month

Choose plan

$82.50 / month (paid yearly)

Choose plan
  • 50 projects
  • 10 team members
  • 5,000 build minutes per month
  • 3 concurrent builds
  • 30 days of log retention

Business

For organisations running production workloads at scale.

$299.00 / month

Choose plan

$249.16 / month (paid yearly)

Choose plan
  • 200 projects
  • 25 team members
  • 20,000 build minutes per month
  • 10 concurrent builds
  • 90 days of log retention

What teams ask before they connect a repository

Short answers about the GitHub deployment and runtime path.

What happens after a GitHub push? A signed event creates an ordered deployment. An isolated BuildKit worker checks out the exact commit, pushes an immutable image digest and publishes a preview after the workload becomes ready.
Why separate builds from runtime? The build boundary receives source access and produces an immutable artifact. Runtime receives only that artifact and environment values — never the repository token.
Which projects can I deploy? The first release supports GitHub repositories with Dockerfiles, Node and Next.js applications, and static builds. Nuxt, SvelteKit and Astro projects work when their production start command serves on port 8080.
How does rollback work? A rollback releases a previously stored image digest with a new production sequence. Traffic changes only after readiness succeeds, without rebuilding source code.
What does ogschaut mean? It is Franconian for having had a look: the preview moment before an approved artifact becomes production.

Ready to ogschau your next release?

Connect GitHub and take the first project from push to production.

Create organisation