# AfterPack Enterprise A custom contract: priority on custom development, a private engine installation in your own cloud, a joint security review, and two deployment shapes for source that cannot leave your infrastructure. Source: https://www.afterpack.dev/docs/enterprise Enterprise is a working relationship rather than a bigger plan, for organizations that cannot let a third party touch their source on that party's infrastructure. Two deployment shapes cover most cases: a Confidential Computing enclave in your own cloud, and an on-prem double-blind install. Both run the full pipeline, with the same [transforms](https://www.afterpack.dev/docs/config#transforms-kind-enabled) and [presets](https://www.afterpack.dev/docs/presets) as the public cloud; only where it runs changes. Enterprise sits above [Studio](https://www.afterpack.dev/docs/tiers). > **Delivered per engagement** > > Everything on this page is scoped, built, and installed under a custom contract. There is no self-serve path and no price list: scope, timeline, and attestation policy are written into the agreement. To keep source on your own machines today with no contract, use [Mode 1, the free local engine](https://www.afterpack.dev/docs/deployment-modes). ## What an engagement delivers - **Priority on custom development.** Your deployment requirements, and the [transforms or preservation rules](#custom-transforms) your stack needs, are worked ahead of the public queue. - **A private engine installation.** The engine runs in your own GCP, AWS, or Azure account, or on hardware inside your perimeter. The two shapes below are the options. - **A joint security and certification process.** We work through your security constraints with your team: questionnaires, architecture review, data-handling terms, and the evidence your auditor asks for. ## Confidential Computing Confidential Computing is [Enterprise](https://www.afterpack.dev/docs/tiers)-only, scoped during onboarding, with attestation policies set per contract. The AfterPack engine runs inside a Confidential Computing enclave in your cloud account (AWS Nitro Enclaves, GCP Confidential Space, Azure Confidential VMs). Your build uploads source to the enclave and receives obfuscated output back, using the same [wire contract](https://www.afterpack.dev/docs/cloud-api) as the public cloud. The enclave is **attested before any source enters it**, so once attestation passes, AfterPack the company cannot see your source, and you can verify that independently on every build. *(Confidential Computing shape: source never leaves your VPC. Your build sends source into an attested AfterPack-CC enclave inside your VPC and receives obfuscated output back. The enclave emits an attestation report to your audit log.)* The enclave proves what is running through hardware-rooted attestation on every build, and a changed binary fails attestation and fails your build. It runs as a sealed binary with no debug interface, no remote management and no [telemetry](https://www.afterpack.dev/docs/config#telemetry-enabled) channel, its network policy permits attestation endpoints only, and each build emits a signed report (input hash, output hash, attestation hash) for your own evidence locker. Your developers change nothing: the [framework plugin](https://www.afterpack.dev/docs/frameworks) and [`npx afterpack@latest`](https://www.afterpack.dev/docs/cli#usage) work as they do on the public cloud, and [`@afterpack` directives](https://www.afterpack.dev/docs/directives) are honored the same way. ## On-prem / double-blind install For Enterprise. The AfterPack engine ships as a sealed binary installed inside your environment: air-gapped data centers, government-adjacent clouds, or anything that cannot reach the public internet at build time. Two properties make it *double-blind*: - **[AfterPack never sees your source.](https://www.afterpack.dev/docs/privacy)** The runtime lives inside your perimeter. There is no callback to AfterPack infrastructure. - **Your team never reads AfterPack's source.** The binary is signed, integrity-verified, and ships without symbols. Reverse-engineering it is contractually prohibited. This deployment targets the strictest government and regulated-industry regimes. It is built and installed for your environment under a custom contract, and the installation and update procedure is agreed with your team before the first build runs. ## SLA and operations Enterprise is the only tier with a contractual, financially-backed uptime SLA: 99.9% annual, compared with the 99.5% monthly SLO the standard [cloud API](https://www.afterpack.dev/docs/cloud-api) runs for [Indie, Team, and Studio](https://www.afterpack.dev/docs/tiers). Incident response, support channels, patch commitments, and data-residency terms are all part of the same contract. See [SLA](https://www.afterpack.dev/docs/sla) for what those targets cover. An on-prem deployment's uptime depends on your own infrastructure. > **Compliance.** A SOC2 Type II report is not available. A [GDPR DPA](https://www.afterpack.dev/docs/privacy), security-posture documentation, and customer-specific addenda are available on request, and an engagement includes working through your own certification process with your team. ## Custom transforms Enterprise engagements can request additions to the [transform catalog](https://www.afterpack.dev/docs/config#transforms-kind-enabled), for example: - A pattern recognizer for a custom DSL or templating language your team uses. - A preservation rule for a proprietary [runtime-reflection](https://www.afterpack.dev/docs/config#reflection-allow) mechanism, beyond what [`identifiers.reserved`](https://www.afterpack.dev/docs/config#identifiers-reserved) covers. - An additional destructive transform tuned to a specific threat, for example trace-replay-hostile binding for anti-cheat. Anti-cheat still needs server-authoritative validation. Read [What AfterPack does not replace](https://www.afterpack.dev/docs/threat-model#what-afterpack-does-not-replace) first. Custom transforms ship as part of your private build of the engine. They are scoped per contract and never added to the public engine. ## When the cloud SaaS isn't enough Three signals tell you you've outgrown the public cloud plans: 1. **Compliance won't approve the cloud touching source** and your auditor wants the runtime in your own environment. → The [free local engine](https://www.afterpack.dev/docs/deployment-modes). 2. **You need transforms that don't exist in the public engine.** → Studio or Enterprise. 3. **You need a custom contract:** [SLAs](https://www.afterpack.dev/docs/sla), indemnification, or data-handling commitments beyond the standard DPA. → Enterprise. If none of these apply, use [Team or Studio](https://www.afterpack.dev/docs/tiers) on the public [cloud](https://www.afterpack.dev/docs/deployment-modes). ## Contact For Enterprise scoping, deployment questions, or custom-transform requests: **support@afterpack.dev**. Typical response time is one business day. Include the scale of code you are protecting (lines or megabytes), your cloud or on-prem requirements, and the compliance regime driving the conversation. --- ## Next - [Deployment modes](https://www.afterpack.dev/docs/deployment-modes): where the engine runs. - [SLA](https://www.afterpack.dev/docs/sla): uptime targets, incident response, and patch commitments. - [Plans & tiers](https://www.afterpack.dev/docs/tiers): the full capability matrix across all plans. - [Builds & promotion](https://www.afterpack.dev/docs/builds): build once, promote the same bytes from dev to prod. - [Privacy & data handling](https://www.afterpack.dev/docs/privacy): residency, sub-processors, and the DPA. - [Threat model](https://www.afterpack.dev/docs/threat-model): the adversary ladder a compliance review will ask about.