Configure / Workflow compatibility
Run your workflows on Gondola.
Start with a representative build. Keep your current workflow available until you are ready to switch.
Runner images and tools
Gondola supports GitHub.com and Linux EC2 fleets on x64 or ARM64. Runner images contain a smaller toolset than GitHub’s ubuntu-latestimage. Install additional tools with setup actions or include them in your own 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 |
Start with a Node, Go, or Docker recipe from the first-build generator, then add your project’s dependencies and build steps.
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 continue to use GitHub's cache service when configured.
Gondola v0.3.0 adds optional S3 caching in your AWS account for dependency directories and exported BuildKit layers. Enable it for selected trusted fleets and use explicit restore and save steps. The S3 caching guide covers fleet setup, the cache action, and dependency and Docker workflow examples. Caching is disabled by default; S3 storage, requests, and transfer remain customer costs.
Compare builds with the same cache state and include queue time and dependency downloads.
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 your results
- 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.
Save deployment and rollback details
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.