# Gondola evaluation pack

Prepared September 5, 2026. A pilot worksheet, not a completed test report,
customer reference, security attestation, or SLA.

## Decide whether the operating model fits

Gondola runs Linux GitHub Actions runners on disposable EC2 instances in your
AWS account. Terraform or OpenTofu defines fleet policy. Controllers run in
your account, verify signed entitlements locally, and contact GitHub and AWS
directly. Gondola does not receive runtime usage telemetry or workflow output.

Start here if your team already owns AWS networking, IAM, GitHub administration,
and infrastructure state. Keep your present runner path available throughout
the pilot. Prefer a private, non-production repository and a limited fleet.

Do not assume compatibility with Windows, macOS, GitHub Enterprise Server,
every preinstalled tool on `ubuntu-latest`, or every container workflow.
Gondola does not provide a managed cache. Minimum runner capacity can retain
idle EC2 runners, with the corresponding AWS cost. Spot launch fallback does
not automatically rerun interrupted workflow jobs.

## Review material

- Installation: https://gondola.build/docs/install
- Workflow/image compatibility: https://gondola.build/docs/workflows
- Architecture and data flows: https://gondola.build/docs/architecture
- Public infrastructure and IAM: https://github.com/gondola-build/terraform-aws-gondola
- Release identity and exact acceptance scope: https://gondola.build/docs/releases
- Supply-chain verification: https://gondola.build/docs/install#release
- Security overview: https://gondola.build/gondola-security-overview.md
- Operations and rollback: https://gondola.build/docs/operations
- Renewal and offline-verification limits: https://gondola.build/docs/licensing#renewal
- Plans: https://gondola.build/#pricing
- Subscription terms: https://gondola.build/legal/subscriptions

Confirm the current references on the release page before deployment. Do not
substitute a mutable image tag for a recorded digest.

## Pilot agreement — complete before provisioning

| Decision | Your record |
| --- | --- |
| Technical owner and backup | |
| Private pilot repository and approved triggers | |
| AWS account, region, VPC, and trust boundary | |
| Explicit egress mode and two subnet Availability Zones | |
| Fleet name, architecture, instance type, maximum capacity | |
| Existing workflow kept for reversal | |
| AWS budget and pilot end date | |
| Success criteria and conditions to stop | |
| Renewal operator and deadline | |
| Who may approve a redacted support attachment | |

Do not put private keys, activation keys, entitlement tokens, Terraform state,
JIT configuration, customer data, or full workflow logs in this worksheet.

## Acceptance sequence

1. Review the generated plan, scoped runner-group access, digest pins, secret
   ARNs, network egress, and protected state. The browser checks field shapes;
   it does not test AWS or GitHub readiness.
2. Run a representative application build, not only an echo or registration
   check. Record the exact workflow and dependencies. Check each architecture
   and any job/service-container path you intend to use.
3. Observe instance termination and GitHub runner deregistration after success,
   an ordinary test failure, and cancellation. Investigate leftover resources.
4. Practice an upgrade in the pilot. Record the prior and new digests and
   deployment generations, readiness, successful build, and rollback path.
5. Practice the renewal procedure when the billing period advances. Compare
   the old and new `expiresAt`, update the existing secret, change the module's
   `deployment_generation_nonce`, and verify readiness on the new generation.
   An early token download may not extend coverage. Calendar imports do not
   rotate secrets or update themselves.
6. Review operating effort and total cost, then adopt, revise, or end the pilot.

## Measurement worksheet

This table is deliberately empty. It becomes evidence only when populated from
observed runs. Use the same repository revision, workload, architecture, and
dependency/cache conditions for the comparison. Record every attempted run,
including failures and retries; do not keep only the fastest samples.

| Field | Baseline | Gondola pilot |
| --- | --- | --- |
| Observation dates and sample count | | |
| Repository revision and workflow | | |
| Controller/module/runner-image references | N/A if hosted | |
| Region, architecture, machine shape | | |
| Cold or warm dependency/cache state | | |
| Workflow dispatch, job creation, job start timestamps | | |
| Queue-to-start: explicitly recorded job creation → start | | |
| Job start → completion | | |
| Complete workflow duration, including dependencies | | |
| Failed attempts and retries | | |
| Instance termination and runner deregistration observed at | | |
| Monthly idle controller/network/storage cost | | |
| EC2, EBS, network, cache, and software cost | | |
| Setup and ongoing operator time | | |

For repeated samples, report median and p95 alongside sample count, range, and
failures. Small samples are exploratory, not a production SLA. Keep raw results
and the collection method in your own account.

`RunnerLaunchLatency` measures the AWS launch call. `JobStartLatency` begins
at instance launch. Neither is full GitHub queue-to-start latency. Do not label
one as the other or compare cold builds with warm baselines without saying so.

## Operator receipt — keep with protected deployment records

Save `terraform output -json gondola` (or the OpenTofu equivalent), plus:

- Exact controller digest, module version, runner image, deployment generation,
  AWS region, fleet label, and known-good rollback reference.
- Protected state location and resource owner; never attach the state itself
  to a routine support request.
- Representative workflow URL and observed cleanup result.
- Current token expiry, next billing period boundary, renewal owner, and a
  reference to the private activation-key vault entry, not the key itself.
- Customer-selected CloudWatch destinations, retention, alarms, notification
  recipient, and the person responsible for responding.
- Teardown plan: route jobs back, drain active work, review the destroy plan in
  the pilot's own state, remove the stack, and check for leftover EC2 instances.
  Separately review the two secrets and the private GitHub App before removal.

## Procurement and support boundaries

The Enterprise plan adds organization scope and priority email support. It is
not a promise of a managed operations team, 24/7 coverage, an uptime SLA, or
independent certification. Gondola does not currently claim SOC 2, ISO 27001,
or an independent penetration-test attestation. Software licensing is separate
from AWS charges; use the current plan and subscription pages for exact terms.

Coverage is Monday–Friday, 10 a.m.–5 p.m. Eastern Time, excluding Canadian
federal and Quebec statutory holidays. Current initial-response targets are
two business days for Business and one for Enterprise and security reports;
these are targets, not guaranteed resolution times. Hobby assistance is
best-effort. Confirm current policy at https://gondola.build/contact.

Send questions to support@gondola.build. Share only deliberately redacted
evidence. There is no requirement to send your runtime analytics to Gondola.