Get started / Workflow compatibility
Bring a build, not just a runner check.
Start with one private repository and a representative build. Keep its current workflow available so the pilot remains reversible.
What the runner image promises
Gondola currently targets GitHub.com and Linux EC2 fleets on x64 or ARM64. The pinned runner image is not a promise that every tool in GitHub's ubuntu-latest image is preinstalled. Install your project's toolchain explicitly or review a custom image.
| Workload | Use in the pilot | Check before moving production |
|---|---|---|
| Node / npm | Pinned checkout and setup-node actions, npm ci, test, build | Node version, lockfile, native libraries, package-registry access |
| Go | Pinned checkout and setup-go actions, go.mod, test and build | CGO dependencies, private modules, target architecture |
| Docker | Build a project image using the runner's Docker access | Registry credentials, disk space, architecture, Dockerfile dependencies |
| Job and service containers | Test the exact workflow separately | Bind mounts, container networking, permissions, and cleanup; a Docker CLI smoke test does not prove this entire path |
The first-build generator provides starting recipes and their prerequisites. Recipe availability is not a published performance result or a guarantee for an untested project.
Caching and cold starts
Every runner is disposable. Do not depend on a previous job's local files, downloaded dependencies, or Docker layers. Setup-action caches use GitHub's cache service when configured; Gondola does not supply a managed cache service. Configure an explicit customer-owned registry cache for Docker if your workflow requires one.
Measure cold and warm-cache builds separately, including queue time and dependency downloads. Do not compare a warm build against a cold baseline and label the difference runner speed.
Permissions and trust boundaries
Keep permissions: contents: read unless the workflow needs more. Prefer GitHub OIDC for job-specific AWS access: add id-token: write only to the jobs that need it and constrain the AWS trust policy to the intended repository, branch or environment. Review that policy with your security owner.
The EC2 instance is the disposable workload boundary. Docker access is powerful and should not be treated as an extra sandbox for untrusted code. Use separate fleets and runner groups for different trust levels; do not admit public fork workloads casually.
Record an honest pilot result
- Repository revision, workflow, runner image, controller digest, fleet shape, region, and architecture.
- Queue-to-start and total build duration, cold/warm-cache state, retries, and whether the build succeeded.
- Instance termination and runner deregistration after success, failure, and cancellation.
- Infrastructure and support effort, not only the EC2 instance price.
Keep these records in your account. Share a redacted copy with support only when you choose; Gondola does not collect runtime usage analytics.
Finish with a reversible handoff
Save terraform output -json gondola or the OpenTofu equivalent with your protected deployment records. Add the workflow URL, state location, fleet owner, renewal deadline, and known-good rollback digest. Never include the private key, activation key, or token in a support attachment.
To end a pilot, route workflows back to their previous runners, wait for active jobs to finish, review a destroy plan in the pilot's own state, and then remove its resources. Verify EC2 cleanup, and separately decide whether to remove the two secrets and private GitHub App. Read the operations procedures.