On-Premise Replit-Style Workspaces That Satisfy Enterprise Security Audits and SOC 2 Controls

Browser-based development workspaces on your own infrastructure remove the shared-tenant boundary that complicates enterprise security reviews. But ownership is not compliance. A deployment satisfies SOC 2 controls only when data isolation, access governance, developer-device hardening, and continuous audit evidence are built into its architecture.

Why shared-tenant dev environments fail enterprise security reviews

A shared-tenant workspace puts the separation between customers inside the provider’s system. That makes isolation harder to prove. Reviewers need evidence that one customer cannot reach another customer’s source code, secrets, build artifacts, or logs. Cross-tenant penetration tests and sampled query logs can become necessary evidence that a dedicated-tenant model does not require.

The concern is sharper because a development platform sits inside the software supply chain. As well as showing business data, it holds repository access and pipeline credentials. A compromise or outage can therefore propagate into customers’ pipelines and production. Enterprise engineering teams want an independent check of security because their own security depends on their toolchain vendors.

Regulation can make the shared boundary unacceptable, although the restrictions differ by industry. Healthcare teams must account for HIPAA and PHI obligations, while government and defense teams may face FedRAMP requirements and air-gapped mandates. EU-regulated enterprises also have to address GDPR restrictions on cross-border data transfers. Financial services requires a more qualified conclusion. PCI DSS adds Appendix A1 controls for multi-tenant providers, but does not outright disqualify them. The failure occurs when the deployment cannot demonstrate the required separation or meet the applicable restrictions.

What SOC 2 auditors actually test in a self-hosted workspace deployment

Moving infrastructure on-premises gives the auditor more to check. The scope includes the facility, network hardware, building access, and the full logical stack. An auditor may check whether cameras cover entrances and exits, who has restricted keys for locked racks, whether visitor logs match badge records, and fire-suppression inspection tags. A cloud provider’s certificate cannot take the place of those tests. Evidence now requires coordination between IT, Facilities, and HR.

Security, as set out in the Common Criteria, is required. It covers access controls, change management, incident response, secrets management, and supply-chain controls. Availability is strongly recommended because workspace or CI/CD downtime blocks deployments and emergency patches. Confidentiality is also strongly recommended because these environments hold proprietary code, artifacts, secrets, and infrastructure configuration. Processing Integrity is situational, becoming relevant when the workspace runs CI/CD pipelines whose build accuracy and artifact integrity must be tamper-evident.

Enterprise buyers usually check customer data isolation first. They then probe secrets management, internal access and logging, encryption at rest and in transit, build isolation, availability and incident communication, change management, and supply-chain incident response. Auditors need evidence of repeatable operation behind those controls. A locked server room fails that test if it has no entry records, as does a firewall with no written process for approving rule changes.

The words in a policy can cause a separate failure before anyone starts to put it into practice. A downloaded SaaS policy may promise phantom controls, such as AWS Inspector and CloudTrail controls that the on-premises deployment does not have. They turn the organization’s own policy into evidence of a gap.

How self-hosted workspace platforms are architected to meet these criteria

Coder provides a documented reference for this architecture. It is a self-hosted cloud development environment platform with SOC 2 Type II certification, deployment across cloud providers or on-premises, and documented air-gapped support. Its validated reference architectures include sizing recommendations for mid-scale deployments and a dedicated high-availability architecture for larger organizations. Terraform-based provisioning makes workspace definitions declarative and reproducible. Kubernetes namespace isolation provides a documented isolation mechanism, while the provisioning definitions give auditors something concrete to examine across the observation period.

The broader design needs four structural properties. These are compute isolation per workspace session, centralized tamper-resistant logs, auditable declarative provisioning, and a defined network perimeter without outbound data paths to the vendor’s cloud. Each build runs in an isolated, ephemeral environment, while a Software Bill of Materials in CycloneDX or SPDX format records the workload’s components. Tools such as Trivy can generate that inventory so teams can assess existing images when a new CVE appears.

A managed deployment takes a different path. Gitpod dropped self-hosting in late 2022 and relaunched as Ona with a managed VPC model. Gitpod Enterprise runs as a single-tenant installation in the customer’s AWS or GCP account, with vendor connections for infrastructure monitoring and updates rather than direct access to source code, running workspaces, or other confidential data. This pattern can meet isolation requirements when vendor access is scoped, monitored, and documented. It is not the same as an air-gapped deployment.

Logs need an equally explicit architecture. Physical servers must send records to a centralized SIEM rather than leave them locally where they can be altered. Audit-log continuity is therefore part of deployment design and must be addressed before the auditor arrives.

Access controls and identity governance that satisfy CC6.1 and CC6.3

Developer platforms hold unusually powerful credentials in one place. API keys, OAuth tokens, repository access, and pipeline credentials make access-control failures especially consequential. Auditors examine how that access is stored, scoped, rotated, and monitored. Authentication alone does not answer those questions. The identity system must also govern who receives access, what they can reach, and when their access ends.

SAML-based SSO connects workspace authentication to the organization’s existing identity provider, such as Okta, Microsoft Entra ID, Google Workspace, or JumpCloud. SCIM provisioning extends that connection to the user lifecycle so a departing developer’s workspace access is revoked automatically. If access is not removed automatically, orphaned accounts can keep their standing access. Granular role-based access controls then define the boundaries within the platform. A developer assigned to one project should not be able to read another project’s secrets or workspace configuration.

Evidence must extend beyond successful and failed logins. Security reviewers want immutable records of workspace access, its timing, and executed commands. WorkOS offers SIEM-ready, tamper-resistant audit logs for compliance evidence as a capability distinct from ordinary application logging for troubleshooting telemetry. Retention also needs a decision before the audit window opens. A SOC 2 Type II observation period lasts at least 12 weeks, but enterprise buyers usually expect to be able to get the records for longer.

A single person should not be able to write, approve, and deploy code without independent oversight or compensating controls. For teams under roughly 50 people, that can create genuine friction. The practical response is a documented second approver in the deployment pipeline, enforced peer review in version control, and records showing consistent use.

Endpoint hardening for developer workstations under SOC 2 CC6.8

A browser workspace does not remove the developer’s device from scope. The workstation used to authenticate remains part of the deployment’s security boundary, whether or not it is enrolled in unified endpoint management. It is especially easy to overlook engineering devices even though they have access to production credentials. Centralizing compute does not settle device security. Auditors still need evidence that the devices connecting to it meet a defensible baseline.

For mixed Mac, Windows, and Linux fleets, that baseline consists of five enforced controls. Password policy must be applied through device management or local operating-system policy, and storage encryption can use FileVault, BitLocker on Windows 11, or LUKS. Anti-malware protection can come from XProtect, Microsoft Defender, ClamAV, or a deployed endpoint detection and response tool. Session timeout and automatic screen lock protect unattended sessions. A local firewall set to default-deny inbound completes the baseline, while CIS Benchmarks provide a hardening standard for servers, network appliances, and hypervisors.

Scope is often the first failure. Contractor devices and personal machines used for production work count, as do devices holding source code or credentials or connecting to the management network inside a trust boundary. Contractor access therefore needs to be managed in the same way or covered by a documented compensating control. BYOD policy must explicitly permit, prohibit, or restrict that use and appear in onboarding documentation. Linux developer workstations require the same documented baseline as corporate laptops.

Phones used for MFA or production access are also in scope. Phones used only for email may fall outside it, depending on an explicit policy. When a fixed-function endpoint cannot run the standard agent, documented compensating controls must cover what the agent would do. Across the observation period, the evidence must show that every in-scope device is known, hardened, encrypted, monitored, and recoverable.

The operational burden of on-prem SOC 2 and how to size it honestly

Cameras, rack access, visitor records, and fire suppression need people to manage the facility as well as take charge of the technical work. Centralized logging needs configuration and maintenance by the customer’s team. Teams need workflows that enforce separation of duties, and must keep collecting evidence as they do their day-to-day work. The Type II process runs 14–16 weeks end to end, including the minimum observation window, so a one-time preparation effort is not enough.

That burden can make self-hosting the wrong economic choice where a compliant hosted option is available. Under stricter requirements, however, the comparison changes. A defense contractor that processed export-controlled satellite imagery had to choose between on-premises infrastructure and specialized government cloud environments that could meet those export controls, such as AWS GovCloud or Azure Government. Standard commercial cloud was effectively disqualified. For teams in that position, a cheaper general SaaS license is not a usable alternative.

Scale also changes the calculation. Organizations facing FedRAMP, HIPAA, or PCI DSS requirements can spread the cost of compliance operations across a growing developer fleet. An independently audited SOC 2 Type II report also removes a major enterprise procurement objection and can shorten security reviews that otherwise take many months. Neither benefit removes the need to fund ongoing operations.

The practical sizing decision is therefore which controls the team must operate itself and which the platform handles. An infrastructure layer that manages clusters, CVE patching, and compliance automation reduces the work of building those capabilities from scratch. The remaining investment is in deploying and governing that platform. This distinction leads directly to the architecture an auditor can walk through.

What a deployment architecture looks like when it is built to pass the audit

The Coder reference architecture provides a concrete anchor for the workspace layer. Terraform definitions govern provisioning, Kubernetes namespaces establish isolation, and the deployment pattern follows the relevant sizing and availability guidance. Around that layer, the network perimeter uses default-deny inbound rules, perimeter firewalls, intrusion detection, and physical port controls. Code, secrets, and session content have no outbound path to a vendor’s shared cloud. Developer endpoints that connect are within the documented device scope and covered by the evidence model.

Identity connects those sessions to the organization’s directory. SAML SSO handles authentication, SCIM governs provisioning and removal, and documented roles limit access to projects and workspace configuration. Secrets belong in a dedicated secrets manager, outside environment variables or configuration files accessible to other sessions. Any vendor monitoring or update access has a defined scope and an audit record.

The evidence layer joins these boundaries together. A centralized SIEM receives records from physical servers, network hardware, workspace sessions, and identity events, with policy-defined retention enforced technically. Immutable workspace-access, command-execution, secrets-access, and deployment records support testing under CC6.1, CC6.2, CC6.3, and CC8.1. Builds run in isolated, ephemeral environments with a Software Bill of Materials per workload. Workspace-template changes go through documented review and approval, linking reproducible provisioning to change-management evidence.

A PaaS layer can reduce the remaining operational work. When it handles cluster upgrades, CVE patches, and network configuration, fewer controls require the customer team to build its own implementation and evidence process. The customer’s deployment is still within audit scope. Certified, documented infrastructure leaves less for the team to collect its own evidence on, while the team keeps responsibility for it.