Hosted runner security model

fremforge hosted runners execute customer Forgejo Actions workflows on single-use T Cloud Public ECS virtual machines in the EU-DE region. Every queued job provisions a fresh VM with embedded Docker; the runner registers ephemerally with Forgejo, picks up exactly one task, runs it, and the VM is destroyed. There is no persistent runner pool that a previous customer’s code could leave residue in.

This page documents the isolation guarantees fremforge makes, the per-tenant limits that apply, and the threat model: what customer code can do, what it can’t, and the design choices a workflow author should make to keep their secrets safe.

Where workflows run

Isolation guarantees

Network isolation (per VM)

Every runner VM gets its own ENI bound to a per-VM Security Group. The SG denies, by default, all traffic except:

• DNS (53/UDP, 53/TCP) to the platform’s internal DNS resolver
• Egress through the runner egress proxy — the only outbound HTTP path

Customer code cannot reach:

• The fremforge api or its private database
• Forgejo’s internal endpoint (runner VMs talk to Forgejo through the public Bunny-fronted apex with a runner-specific scope; the internal endpoint is unreachable)
• T Cloud Public platform services (RDS, DCS, OBS, SFS-Turbo, IAM, KMS)
• Other tenants’ runner VMs
• The cluster’s metadata IP (169.254.169.254) — explicitly blocked at the SSRF guard
• RFC1918 private ranges or loopback

The Security Group is applied at VM provisioning and cannot be modified from inside the VM — the VM has no IAM agency attached, so the network-config APIs are unreachable through the metadata-derived identity.

Outbound egress

Customer workflow steps that need the public internet (cloning a public repo, downloading a tool, calling a SaaS API) route through the runner egress proxy via HTTPS_PROXY injected into the VM. This proxy:

• Accepts any public unicast IP including Carrier-Grade NAT (matches GitHub-hosted runner behaviour — needed for T Cloud Public’s own services like SWR which sit in CGNAT)
• Blocks RFC1918 private, link-local, loopback, multicast, reserved, and explicit cloud-metadata IPs (169.254.169.254, T Cloud Public’s 100.100.100.200)
• Logs every CONNECT tunnel attempt with hostname + resolved IP for audit retention

The proxy is deliberately permissive in the GitHub-hosted-runner sense: customer workflows can reach any public host they need. The boundary is at SSRF + internal-platform, not at vendor allowlists.

Package caches (sovereign, EU-resident)

Before a workflow reaches the public internet, the common package-manager fetches are routed through in-VPC pull-through caches — EU-resident, fast, and they keep dependency traffic off US-hosted public indexes. Each runner has these injected as the default index/registry:

For the common case (public dependencies) this is transparent — the caches proxy the public index, so nothing in your workflow changes.

If you use a private index or registry, note the injected value is the default, so it takes precedence over a default configured in a committed config file (pip.conf, .npmrc, go env). Point your private source explicitly so it wins:

• pip: pip install --index-url <your-private> ... (a CLI --index-url overrides the injected PIP_INDEX_URL), or set it in the workflow step’s env:. To add a private index alongside the cache, use --extra-index-url.
• npm: scope your private registry in .npmrc with a @scope:registry= line (scoped registries are honoured alongside the default), or set NPM_CONFIG_REGISTRY in the step env:.
• Go: set GOPRIVATE (e.g. GOPRIVATE=git.example.com/*) so the toolchain bypasses the proxy + checksum DB for your private module paths.

VM-level isolation

Cross-tenant + intra-tenant kernel isolation

This is the load-bearing claim of the hosted-runner model. Every queued job gets its own ECS VM — a guest Linux kernel running on T Cloud Public’s hypervisor. The runner registers, runs the job, exits, and the platform destroys the VM. The next job (same tenant or another) gets a fresh VM with a fresh kernel.

Per-tenant limits

When a tenant exceeds the runner-minute pool and overage isn’t enabled (or is frozen), the platform refuses dispatch: the workflow’s queued job transitions to Cancelled in Forgejo. Tenants with overage enabled keep running and are invoiced for the excess.

When a tenant hits the concurrent cap, additional queued jobs wait and are dispatched as soon as a slot frees.

What customer code can NOT do

• Reach the fremforge api, Forgejo’s internal endpoint, or any other platform service (the api is only available through the public Bunny apex with proper authentication, just like for any external caller)
• Read another tenant’s runner VM (separate ENI; cross-VM traffic explicitly denied at the Security Group)
• Read another tenant’s secrets (workflow secrets are passed only to the runner that’s running the workflow that owns them; VM destruction wipes the in-memory credentials)
• Persist state across job invocations (single-task VM, no shared disk)
• Reach the OTC API directly with privileged scope (no IAM agency attached; metadata-derived identity has no roles)
• Reach cloud metadata endpoints (169.254.169.254, 100.100.100.200 — both explicitly denied at the SSRF guard)
• Exhaust the runner pool (per-tenant concurrent cap + the platform’s global compute ceiling)
• Cause queue starvation across tenants (per-tenant concurrent cap)
• Escape the hypervisor (the VM is the boundary; the host below it is T Cloud Public’s, isolated by the same VMM that separates every commercial ECS tenant in the region)

Recommended workflow shapes

Split validate and apply jobs

Run untrusted code (PR builds, dependency scans, contributor-supplied test fixtures) in a validate job with no production credentials, and gate the apply job behind an environment approval. A compromised validate job cannot reach apply-job secrets.

Pin uses: references by SHA when supply-chain matters

uses: actions/checkout@v4 resolves to frem.sh/actions/checkout (fremforge’s Forgejo native pull-mirror of github.com/actions/checkout, 8-hour sync). The mirror tracks upstream tags including force-pushes, so pinning by SHA is the only way to guarantee bytewise stability:

# Bytewise-stable across maintainer force-pushes
- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5  # v4.2.0

# Picks up upstream's current HEAD at last mirror sync — including
# any maintainer-credential-compromise force-push
- uses: actions/checkout@v4

Use OIDC for cloud auth, not long-lived secrets

Every runner VM gets a fresh OIDC token with aud=fremforge. Configure your cloud provider’s trust policy to accept this token and exchange it for short-lived credentials. Avoid storing long-lived AWS access keys / GCP service-account JSONs in workflow secrets where they end up in process env.

Cap workflow step deadlines

Set timeout-minutes: on individual steps to bound how long a hung step can run. The VM-level wall-clock cap (activeDeadlineSeconds=3600) is the platform floor; step-level timeouts give faster feedback.

Threat-model summary

Auditability

Every dispatch is logged in three places:

1. runner_jobs table — tenant_id, repo, forgejo_task_id, started_at, finished_at, duration_seconds, vm_id. Source for billing aggregation and the operator console’s Infrastructure tab
2. metering_events table — code=runner_minute rows derived from runner_jobs.duration_seconds. Drives invoice line items and the tenant’s “Runner minutes used” panel
3. Operator log stream — structured spawn logs for the operator, with continuous alerting on dispatch refusals, stuck VMs, overrun deadlines, and capacity exhaustion

Tenants see their own usage at Org admin → CI runners → Usage, including a per-month minute count and a per-job durations table.