Sengi service terms

Draft. Not published, and not reviewed by a lawyer. Every token in [SQUARE_BRACKETS] is an unfilled deployment input. This document is not ready to show a customer until each token is replaced with a real value and the whole text has had legal review. The clause-by-clause map of what each statement is based on is in beta-terms-review.md.

Effective from [EFFECTIVE_DATE]. These terms are between you (the account holder and the organization you act for) and [BUSINESS_LEGAL_NAME], which operates the Sengi service at [SERVICE_DOMAIN].

Where something works today, this document says what it does. Where it does not exist yet, it says not yet available rather than promising it. We would rather you find this document boring than find it optimistic.

1. The service

1.1 Sengi runs GitHub Actions jobs on machines we operate, so that you can keep using GitHub Actions and stop paying GitHub's runner rates. You keep your workflows, your triggers, your secrets and your merge decisions in GitHub; we supply the machine the job runs on.

1.2 We offer three runner sizes, all on the same Ubuntu 24.04 x64 image: 2 vCPU / 8 GB, 4 vCPU / 16 GB and 8 vCPU / 32 GB. Each job gets its own fresh virtual machine.

1.3 Available today: creating an account and signing in with GitHub.

1.4 Not yet available: runner activation and paid execution. No execution host has completed qualification, no payment provider account is configured, and no customer job has run on Sengi. When you can activate runners, we will say so on the site; until then an account is a placeholder, not a running service.

1.5 Not offered: Windows, macOS or ARM runners; virtual machines, managed databases, Kubernetes, private networking or any other cloud product. Those product areas are refused server-side for customer accounts, not merely hidden from the menu.

1.6 Not offered: interactive SSH access into a runner for debugging, accelerated or proxied build caching, and a command-line tool. Ordinary GitHub Actions cache steps keep working; the accelerated cache product some other providers sell is deliberately disabled here.

Based on: one-click-beta-direction.md (Product contract, Initial deployment, Scaling and exclusions); payg-policy-v1.md (Rates and authority); runner-only-authority.md and trust-boundaries.md §4; runner-runtime-qualification.md; github-invoice-export.md; sengi-output-branding.md.

2. Your account and your GitHub authority

2.1 Sengi accounts are created only by signing in with GitHub. We store the numeric GitHub user ID, the profile GitHub returns to us, and your verified primary email address. New accounts have no Sengi password. We do not store the GitHub OAuth token from sign-in.

2.2 Your work lives in a Project. The Project owns the GitHub App installation, the approved repositories, the job history, the spending allowance and the invoices. People you add to the Project can see the Project's data; someone with Project:billing permission can act on billing.

2.3 You install our GitHub App and you choose which repositories it may see. Choosing "all repositories" in GitHub does not enable them in Sengi: you still have to enable each repository here explicitly. GitHub keeps your workflow definitions, secrets, environment approvals, triggers, logs and merge decisions.

2.4 The App asks for Administration: write so it can register a just-in-time runner for a job, and for Contents: write, Workflows: write and Pull requests: write so it can open the migration pull request. Signing in to Sengi is a separate authorization from installing the App.

2.5 We never store an installation access token. Where a call to GitHub goes through the scoped helper, the token is minted for the exact repository IDs and the minimum permissions that call needs, and it is discarded with the client. Not yet complete: several existing callers — the runner lifecycle, the repository poller and operator job-log retrieval — still use a broader installation-wide token, and their migration to scoped tokens is unfinished.

2.6 We cannot configure your side for you, by design. No operator route exists to create your installation binding, approve a repository, edit workflow YAML, mint or paste a token, or choose a runner label. Those all require your own fresh authorization. If you get stuck, the right outcome is that we fix the product, not that we hand-configure your account.

2.7 If you revoke your personal GitHub authorization, we withdraw your connection consent and move your activation to "action needed"; that alone does not uninstall the App for your organization or touch other members, repositories or jobs. If the App is uninstalled, we stop being able to act on your repositories. Neither deletes records we already hold (see §5).

Based on: github-sign-in.md; permission-scoping.md; github-scoped-tokens.md; github-actor-revocation.md; trust-boundaries.md B2, B4, B5 and §5; beta-approval-and-exceptions.md ("The boundary this document exists to hold").

3. What we change in your repository

3.1 After you select jobs and approve an exact preview, Sengi opens a pull request that changes only the runs-on value of the jobs you selected. Quote style, comments, line endings, triggers, permissions, steps, conditions and every job you did not select are preserved untouched.

3.2 We only support jobs whose runs-on is a single plain value of ubuntu-latest, ubuntu-24.04 or ubicloud-premium-2. Jobs that build their runner name from an expression or a matrix, reusable workflow calls, runner sequences, and files we cannot parse safely are reported as unsupported rather than guessed at. We will not repair unrelated workflow content.

3.3 You review and merge the pull request; GitHub's normal checks and approvals apply. Note that publishing the branch can itself trigger CI in your repository before the pull request exists.

3.4 To go back, revert that pull request. Future jobs then use your previous runners again.

Based on: workflow-support.md; github-migration-consent.md; one-click-beta-direction.md (Setup behavior, Compatibility and operations).

4. Acceptable use

4.1 Sengi is for running your own continuous integration. Please do not use it for:

• cryptocurrency mining or similar proof-of-work;
• sending unsolicited bulk email, or relaying mail for third parties;
• scanning, denial-of-service, credential stuffing or other attacks against anyone;
• hosting a persistent public service, a proxy, a VPN exit or a tunnel;
• distributing malware, or content you have no right to distribute;
• attempting to reach the host, the control plane, our management network or another customer's runner from inside your job;
• working around admission, spending or concurrency limits, or the approval that lets your Project spend at all.

4.2 Be aware of what we can and cannot enforce. Your job runs as root in its own virtual machine with routed public IPv4 and IPv6, because Actions jobs must reach GitHub, package mirrors and your own dependencies. A destination policy exists in our source that denies outbound SMTP (ports 25, 465 and 587), our own host and control addresses, other tenants' ranges and private or reserved destinations — but it only applies to runners created under a reviewed network profile, and no such profile is configured yet. Cryptocurrency mining, abusive traffic to public destinations and the other items in §4.1 have no technical block at all and are not intended to have one. §4.1 is therefore an agreement. We act on abuse after the fact.

4.3 How we act on abuse. We may, in this order of seriousness: stop new runner work for your Project (reversible, and it does not kill jobs that are already running); terminate your Project's runners in a scoped incident action; and suspend an account for fraud or abuse spanning several Projects. Suspending an account signs out its sessions, disables its API tokens and affects every Project that account belongs to.

4.4 Every one of those actions requires an operator to be signed in with a hardware second factor and to record a written reason. Stopping and resuming runner work and the incident termination each write an audit row automatically; suspending an account does not yet, and is recorded by hand.

4.5 Ordinary high CPU use is not evidence of abuse and will not be treated as such. If we act, we will tell you in writing: what we did, when in UTC, whether running jobs were left to finish or stopped, and what we need from you. We will not quote your workflow content back to you or attach it to a report, and we will not assert a cause we cannot evidence.

4.6 If we stop your work, usage already recorded stays as it is and no new charges accrue while jobs are paused. If we terminate running jobs, we bill the execution that actually happened up to the stop, with no penalty and no extra fee.

Based on: abuse-and-compromise.md A.0–A.7; runner-operator-controls.md; foundation.md#abuse-controls; trust-boundaries.md §6 and B8; payg-policy-v1.md (Outcomes and infrastructure credits); one-click-beta-direction.md (Compatibility and operations).

5. Your data: what we keep, and for how long

5.1 What we hold.

• Account: your numeric GitHub user ID, the profile GitHub gives us, and your verified primary email address.
• Connection: your GitHub App installation and the repositories you approved, by numeric identity and name.
• The change you approved: the exact preview of the runs-on edit, the source snapshot it was computed from, and your consent record. These fields are encrypted in our database.
• Job records: run and attempt IDs, job status, conclusion and timestamps, the runner size, image and host it ran on, the allocation, the seconds we metered, the amounts, any adjustments, and the cleanup observations that prove the machine was released.
• Billing: your billing details, your payment-provider customer and payment-method binding, and your invoices.

5.2 What we do not hold.

• Your job logs. Those stay in GitHub, and we link to them there.
• Your repository secrets, environment variables or workflow run outputs.
• Your GitHub OAuth token, or GitHub installation access tokens — neither is written to our database.
• Anything on the job's disk. Each job gets a fresh virtual machine; its disk is destroyed with the machine, and ephemeral job disks are deliberately excluded from our backups.

5.3 How long we keep it. Exactly this, and no more than this:

Optional job and workflow titles may expire after 90 days without new activity. Eligible processed delivery details may expire after 30 days. We keep the execution, billing and unresolved-incident records needed to explain your job history and prevent duplicate charges.

Those are eligibility thresholds, not deadlines: a backlog, an unresolved incident or an unsettled charge can keep a record longer. We do not promise that a job title is erased from every retained evidence source — accounting and signed-delivery evidence can legitimately contain the same text.

5.4 What we do not delete. Canonical job records, usage, adjustments, reservations, cleanup observations and invoices are never deleted automatically. Uninstalling the GitHub App, disconnecting a repository or deleting a runner does not erase job history; it stays with the Project that owned it. That is deliberate: it is how we can explain a charge to you and how we avoid billing you twice for one job.

5.5 Not yet available: a self-service data export, and a customer-initiated erasure request path. If you need either today, write to [PRIVACY_EMAIL] and it is handled by hand.

5.6 Backups. The control database is backed up as a whole and encrypted, which necessarily includes the encrypted customer fields listed in §5.1. Not yet available: off-host backup custody, a published retention period for backups, a recovery-point objective, and a rehearsed live recovery. What has been done is a local rehearsal against test data.

5.7 In your browser. The public site loads only our own assets. The signed-in application loads pinned, integrity-checked JavaScript from the jsDelivr CDN, and some forms load Cloudflare Turnstile. We do not run analytics, advertising or session-recording services.

Based on: github-job-retention.md; github-job-history.md; github-sign-in.md; trust-boundaries.md §5; backup-restore.md; one-click-beta-direction.md (Compatibility and operations); app/views/layouts/app.erb and app/views/layouts/marketing.erb.

6. Security and isolation, as actually implemented

6.1 What is implemented. Every job runs in its own fresh virtual machine, in its own network namespace, with its own network interface, its own encrypted disk and its own resource slice with CPU, memory and I/O limits, all destroyed at the end of the job. Inbound traffic to the runner network is restricted to SSH from our control plane. Traffic leaving the machine is checked against the machine's own identity, so a job cannot forge another runner's address. We treat your job as untrusted and hand it as little as possible: no runtime API token, no cache URL and no cache-proxy binary reach a Sengi runner, and the one-use GitHub registration credential is delivered over an unlogged input stream into a file readable only by the runner user.

6.2 What is written but not yet in force. A per-runner destination policy that denies our host and control addresses, other tenants' address pools, private and reserved destinations and outbound SMTP, and that permits public build traffic, DNS only to the runner's own resolver and only the ICMP that relates to a connection you made, exists in our source and passes 66 packet checks in a test harness. It applies only to runners created under a reviewed network profile, and the shipped profile is empty. Until a host is qualified with a real profile, treat the destination policy as designed, not as protecting you.

6.3 What is not proven, stated plainly.

• The network filtering has not been proven on the real platform. Every packet check so far ran against virtual interfaces inside a container on a different CPU architecture, not against a real guest on the intended x64 host. Live guest-to-host, guest-to-control-plane and guest-to-peer isolation testing is still open.
• Same-host public traffic between namespaces is not denied by the routed path itself.
• No certification and no penetration test. Our internal security review is a source review tied to automated tests, not an audit, and it does not qualify any live host, image or GitHub App.
• No credential rotation procedure exists yet for several of our own secrets.

6.4 Reporting a vulnerability. Send it to [SECURITY_EMAIL]. Please do not open a public issue.

6.5 Our operator console runs as a separate application on a separate hostname with its own accounts and a mandatory hardware second factor. A customer session cookie or API token replayed against it grants no operator access; this is tested.

6.6 If we ever believe a host has been compromised, we will drain it, isolate it, rotate the credentials that reached it, rebuild it, and reconcile your retained jobs without silently re-running your code. Not yet available: that procedure has never been rehearsed against a live host.

Based on: trust-boundaries.md (header, B7, B8, B10, B11, §5, §6, §9); runner-network-isolation.md ("Qualified destination policy", "Destination qualification", "Operator inputs, compatibility and live gate"); runner-resource-containment.md; abuse-and-compromise.md Part B and Part C.

7. Operator access to your data

7.1 Named operators of [BUSINESS_LEGAL_NAME] can read your Project's records in the operator console — the Project, its installation, repositories, jobs, allocations, reservations, invoices and payment state — in order to answer a support request or investigate an incident. Signing in requires a password and a hardware second factor.

7.2 Every object action an operator takes writes an audit row, and the actions that change anything require a written reason of 1–500 characters.

7.3 Operators can: set your Project's runner CPU quota, stop and resume runner admission, terminate your Project's runners in an incident, add account credit, and suspend an account.

7.4 Operators cannot: bind your GitHub installation, approve a repository, consent on your behalf, edit workflow YAML, mint or paste a token, or choose a runner label. There is no route that does any of these, and none will be added to make an onboarding demo work.

7.5 Two honest limits. First, when an operator retrieves a job log from GitHub for support, that retrieval uses an installation-wide token, so it is not narrowed to the single job in question. Second, the control database contains your encrypted private fields, and whoever holds the deployment secret store can decrypt them; the isolation is organizational, not cryptographic, with respect to us.

Based on: beta-approval-and-exceptions.md (Operator access, §1.4–§1.8, §4.1); trust-boundaries.md B10 and B12; runner-operator-controls.md.

8. Pricing and billing

8.1 Rates. You pay for execution seconds, at these rates:

Word for word, as our pricing policy records it: "Rates are 50/100/200 integer micro-USD per execution second for the existing 2/8, 4/16 and 8/32 choices, equivalent to $0.003/$0.006/$0.012 per minute." One US dollar is 1,000,000 micro-USD. Amounts are USD service usage before separately itemized applicable tax.

8.2 No minimum, no subscription. There is no monthly minimum, subscription, base fee, minimum job charge or minimum top-up. No VM, boot, idle, teardown, storage, IP, concurrency or inherited free-runner-credit line is added to these service usage amounts. $0 of usage costs $0.

8.3 What is billed. We bill the verified GitHub start-to-completion interval of the job that actually ran, from started_at up to but not including completed_at. That includes setup inside the GitHub job, all of your steps, and post-job actions such as cache and artifact cleanup, through to terminal completion. It excludes GitHub's own queueing, our virtual-machine provisioning, the wait before GitHub assigns your job to a ready runner, and all host and machine cleanup after the job finishes.

8.4 Whole seconds. We meter complete elapsed seconds. A verified job shorter than one second is zero seconds, which is not the same as a job whose evidence is missing.

8.5 Outcomes.

8.6 How long a job may run. An allocation gets a six-hour execution window from the moment the host is armed, plus a 30-second stop grace. The wait before GitHub assigns your job consumes part of that window, so this is not a promise of six hours of useful job time and it is not parity with GitHub's own job timeout. Your own timeout-minutes still applies and can end a job earlier. If our window stops a job that would otherwise have finished, we treat it as a service timeout and credit the whole affected job.

8.7 Periods and rounding. Service periods are UTC calendar months. A job crossing midnight on the first of a month is split at the boundary and each part is billed to its own month. Rounding to cents happens once, on the finalized invoice, to the nearest cent with ties rounded up. There is no per-job, per-shape or per-line rounding.

8.8 Rate stability. The rate is locked when your job is admitted, and stays locked through provisioning, execution, cancellation, settlement and the month rollover, even if a newer rate becomes effective in the meantime. We do not retroactively change past charges, discounts or duration rules. If we change rates in the future, the new rate applies from an explicit effective time and you will be asked to consent again before it applies to you.

8.9 Spending allowance. Your Project has a spending allowance: a cap on how much unsettled and settled execution we will let it accumulate before new jobs are refused. It is an admission control, not a recurring fee, and setting it does not charge you anything. It is not a monthly-reset spending cap. It does not reset at month rollover, and paying an invoice does not replenish it — only an explicit, authorized allowance change does. If the remaining allowance is too small for a job, that job queues; we will never silently shorten your execution time or give you a smaller runner instead.

8.10 Payment. You add a card yourself, on the payment provider's own hosted setup page. That page saves the card; it does not charge it. Card details go to the provider, never to us. There is no automatic debit. Invoices are issued through the provider, with its numbering, tax calculation and PDF, and paying an invoice is an explicit action you take on the provider's hosted page. A saved and verified card means exactly that a usable card is on file — it is not a statement about your standing, your allowance, or whether a future charge will succeed.

8.11 Very small invoices. If a positive amount is below the payment processor's collection minimum, we record a waiver on that invoice and show zero due, keeping the original usage and the reason visible. We do not call it paid, and we do not quietly write off a debt. A zero-cent invoice gets no payment attempt at all.

8.12 Not yet available: production issuer, tax registration and merchant configuration; hosted collection; automatic preparation of invoices. No live invoice has been issued and no payment has been taken. Until these are configured and qualified, paid activation is held.

8.13 Not yet available: there is no operator-facing way to set a Project spending allowance yet, so a billable Project's paid admission currently holds rather than running. That is the intended fail-closed behaviour, not a bug in your account.

Based on: payg-policy-v1.md (all sections; §8.1 and §8.2 quote "Rates and authority" verbatim); github-runner-exposure.md; github-execution-invoice.md; github-invoice-export.md; github-invoice-initiation.md; github-payment-setup.md; beta-approval-and-exceptions.md §1.5.

9. Infrastructure credits

9.1 If a verified Sengi host, image, bootstrap or runtime fault aborts a job of yours — including a job stopped because our own execution window ran out — we keep the real duration and the real gross amount on record and add a credit for the whole of that job's invoiceable usage. Net, you pay nothing for that job.

9.2 A GitHub conclusion of failure is not by itself evidence of a Sengi fault. A failing test is your result, not ours.

9.3 Credits do not expire, and there is no monthly claim cutoff. Unused credit stays with the Project that earned it. We will not discard it at a month rollover and we will not move it to another Project.

9.4 If the affected invoice is still open, the credit reduces it. If that invoice was already finalized, we leave it alone and put an explicit correction on your next open invoice, citing the original job and its service period. You are owed it even if you already paid the original invoice.

9.5 A period that is nothing but credit produces an adjustment statement, never a negative charge. All credits for one incident or job together can never exceed that job's gross usage, and replaying a webhook or reconciling twice never grants a second credit.

9.6 Not offered: general promotional or goodwill credits, and automatic refunds. If a Project closes with credit remaining, we retain it for an operator to resolve with you by hand.

Based on: payg-policy-v1.md (Outcomes and infrastructure credits; UTC periods, exact aggregation and collection).

10. Availability, maintenance and support

10.1 One host, and no high availability. Sengi runs on a single execution host with a separate control-plane machine. There is no second host to take over, no failover, no clustering and no live migration. We do not offer an uptime commitment or a service-level agreement, and nothing in this document should be read as one. If the execution host is unavailable, your jobs queue or fail, and your workflows are affected until it comes back.

10.2 We keep our repair access independent of the execution host, so a host being down does not also lock us out of fixing it.

10.3 Not yet available: a status page, a maintenance-window notice channel and a rehearsed outage-communication procedure. Until those exist, we will contact you at your account email address, and outage notices will come from [STATUS_UPDATE_CHANNEL].

10.4 Capacity. Jobs above your Project's runner CPU quota, or above what the host can currently place, queue and start when capacity frees up. We do not overflow your jobs to another provider, and we do not silently upgrade you to a larger runner.

10.5 Support. Write to [SUPPORT_EMAIL]. Support is staffed [SUPPORT_HOURS] and we aim to reply first within [SUPPORT_FIRST_RESPONSE_TARGET]. These are targets we work to, not guarantees, and they are not a service-level agreement. Billing questions go to [BILLING_EMAIL]; report abuse of Sengi to [ABUSE_EMAIL].

10.6 What support can do: find your exact job from a Sengi job reference without you copying any secret; explain why a job is queued, held or unresolved; resume runner admission after a pause; and correct a billing record with an auditable adjustment.

10.7 What support cannot do: run, retry or reconcile a GitHub job on your behalf; complete your activation for you; or see your job logs except through the same GitHub links you have.

10.8 What you can see yourself: your Project's job history with the size, image, timing and status of each job and a link to the run in GitHub; your held reserved capacity, labelled as reservations rather than as host utilisation or free capacity; and a billing page showing a usage estimate from settled usage and adjustments, jobs still being processed kept out of that total, your payment-method status, your credits and your invoices. The estimate is what we have settled so far, not an amount due.

Based on: one-click-beta-direction.md (Initial deployment; Scaling and exclusions; Compatibility and operations); github-job-history.md; runner-visibility-readiness.md; github-billing-presentation.md; beta-approval-and-exceptions.md §2, §3; abuse-and-compromise.md A.6; backup-restore.md.

11. Source code

11.1 Sengi is built on Ubicloud and is used and distributed under the GNU Affero General Public License. We keep the upstream notices, we identify our modifications, and we make the corresponding source of the deployed version available together with the material needed to build and install it.

11.2 The deployed application shows a "Source code for this release" link when the published archive matches the exact commit that is deployed. If it is not configured, no link is shown rather than a link to something else.

11.3 The source release contains no customer data and no production credentials.

11.4 Third-party components, their versions and their licences are listed in the project's THIRD_PARTY.md.

11.5 Not yet available: nothing has been published yet. Source availability becomes real when a version is deployed and its archive is published at [SOURCE_RELEASE_URL].

Based on: corresponding-source-release.md; THIRD_PARTY.md; one-click-beta-direction.md (Licensing and upstream maintenance).

12. Third parties we rely on

We are not currently able to promise a fixed list of sub-processors beyond this table, and we will update this table before adding another one.

Based on: one-click-beta-direction.md; github-invoice-export.md; github-payment-setup.md; sengi-output-branding.md (MAIL_FROM, INVOICES_BUCKET_NAME); app/views/layouts/app.erb.

13. Changing, pausing and ending

13.1 You can stop at any time. Revert the migration pull request, disconnect a repository, or uninstall the GitHub App. There is no term, no notice period and no cancellation fee, because there is no subscription to cancel.

13.2 What happens when you disconnect a repository. Disconnecting is a change on our side: we withdraw that repository's approval so no new runner can be granted for it, and we do not call GitHub, uninstall your App or edit your workflow files. Work already running is allowed to finish, and work we can still cancel before the runner registers is cancelled; a registration credential already handed to GitHub cannot be recalled cleanly, so a job may still start. All of it is billed by the ordinary rules in §8. Uninstalling the App is your action in GitHub; when we see it, we wait for your runners and repositories to drain before cleaning up.

13.3 Revoking authorization, disconnecting a repository or uninstalling the App does not erase the history of what already ran, and does not cancel an amount you already owe.

13.4 We may pause you as described in §4.3, or if an invoice goes unpaid. A pause stops new jobs; it does not delete anything.

13.5 We may end the service for a Project with [NOTICE_PERIOD_DAYS] days' written notice to your account email, or immediately where §4 or the law requires it. On ending, we stop new jobs, let running work finish where it is safe to, issue a final statement for usage actually incurred, and keep the records described in §5.4.

13.6 We may change these terms. We will publish the changed version and email your account address before the change applies to new usage. A rate change never reprices a job that was already admitted at the old rate.

13.7 Not yet available: uninstall, revocation and revert have not been qualified against live GitHub behaviour, so treat §13.1 to §13.3 as our design intent rather than as tested behaviour.

Based on: payg-policy-v1.md (Outcomes and infrastructure credits; Rates and authority); github-repository-disable.md; github-actor-revocation.md; one-click-beta-direction.md.

14. Who we are, and how to reach us

These terms are governed by the law of [JURISDICTION], and disputes go to the courts of [JURISDICTION].

No part of this document has been reviewed by a lawyer, and no clause here has been tested against live service behaviour. Its factual claims are drawn from the implementation records cited under each section; where an implementation record says something is unqualified, this document says "not yet available" rather than making a commitment.