OpenShift Developer Sandbox vs paid tier, at the boundary.

OpenShift Developer Sandbox is a hosted free tier that Red Hat runs on its own infrastructure for individual developers. The sandbox provides a single namespace, a small CPU and memory quota, a thirty day initial term that the developer may renew, and access to a curated set of operators and developer tools. The sandbox is registered against the developer's personal Red Hat account on developers.redhat.com1. The sandbox is not a cluster the buyer's organisation owns and is not in the enterprise contract record.

The paid OpenShift tier covers everything else. Self managed OpenShift Container Platform, OpenShift Dedicated, Red Hat OpenShift Service on AWS, OpenShift on Azure, IBM Cloud, and GCP all sit on the paid side. Each is subscribed at cluster level with entitlements counted in cores, sockets, or virtual machines depending on the variant, and each is named in the enterprise contract record with the cluster identifier, the term, and the support tier explicit2.

The buyer who has both kinds of presence on a single calendar typically maintains them through different teams: a developer enablement team curates sandbox access for individual engineers, and a platform engineering team operates the paid clusters under the enterprise contract. The audit reads the paid side cleanly. The sandbox side reads cleanly only if the buyer can produce the enrolment record and the tier policy that separates personal evaluation from production project work.

The boundary blurs in four places that the practice observes across engagements. The first is the developer who uses the sandbox to prototype an internal application, demonstrates the prototype to a stakeholder, and is then asked to operate the prototype as an internal service. The sandbox keeps running because it works; no formal migration to the paid tier is requested. At audit the prototype reads as a small production workload running on infrastructure the buyer's organisation did not subscribe.

The second blur is the team that uses the sandbox to host a continuous integration scratch environment for a project that is otherwise paid. The CI scratch is the developer's choice, and the developer treats the sandbox as a personal resource. The audit reads the CI scratch against the project record and questions whether the sandbox supported a buyer funded engineering effort that should have run on the paid tier.

The third blur is the trainer who uses sandbox access to teach a workshop with twenty employees of the same organisation. Each employee registers an individual sandbox under a personal account. The audit reads the training event against the organisation's name and the enrolment timestamps and questions whether the twenty employee cohort constituted an organisational use that should have been routed through OpenShift Dev Spaces or a small paid cluster.

The fourth blur is the project that begins on the sandbox, migrates to the paid tier, but leaves the original sandbox running with the production application's name still attached. The audit reads the namespace name and the migration log and questions whether the sandbox remained a fallback for the production workload during the migration window3.

The buyer who anticipates the boundary writes a tier policy and circulates it through the developer enablement function. The policy distinguishes personal evaluation, training, prototype work, and internal service in language a developer can read without ambiguity. Personal evaluation and training are explicitly sandbox eligible. Prototype work is sandbox eligible only at the individual level for a maximum of thirty days; any prototype that crosses thirty days, accepts inbound traffic, or names a customer use case migrates to the paid tier under a documented migration ticket. Internal service is paid tier only; the sandbox is not a fallback during downtime, not a CI scratch for paid projects, and not an evaluation surface for production workloads.

The policy is paired with an enrolment record. The developer enablement function collects sandbox enrolment by name and date, retains it for the audit window, and reconciles enrolment against the broader engineering headcount each quarter. An enrolment record the buyer maintains is read as evidence of intent; an unrecorded enrolment is read against the buyer in the audit response.

The migration path from sandbox to paid is named explicitly. The buyer reserves a small paid cluster, often a single node OpenShift footprint or a three node compact cluster, as the receiving environment for prototypes that cross the sandbox threshold. The receiving environment is in the contract record, has named owners, and reads cleanly at audit. The buyer who maintains the receiving environment as an audit boundary settles cleanly; the buyer who relies on the sandbox indefinitely pays the difference in the audit settlement4.

The audit response on a sandbox question turns on three artefacts. The first is the tier policy itself, which establishes the buyer's intent. The second is the enrolment record by name and date, which establishes who enrolled and when. The third is the migration record from sandbox to paid where any prototype crossed the boundary, which establishes that the buyer acted on the policy when the boundary was approached. A buyer who produces the three artefacts settles a sandbox question quickly; a buyer who produces only one or two settles at a partial reading that the audit treats as an open question for the next term.

For the broader cross product reading, see the OpenShift practice hub, the Dev Spaces read for the hosted IDE alternative that the buyer often pairs with a paid cluster, the single node and three node read for the receiving environment pattern, the OpenShift AI LLM workload read for the workloads that should never sit on the sandbox, and the developer program enterprise read for the broader developer subscription posture inside the enterprise. For the engagement protocol, see renewal negotiation and contact.

OpenShift Developer Sandbox vs paid tier reads as a boundary the buyer enforces in policy, in enrolment, and in migration record. The sandbox is a personal resource on Red Hat infrastructure that the audit cannot attribute to the enterprise contract absent a buyer signal. The buyer who keeps the boundary clean settles cleanly; the buyer who lets the sandbox subsidise paid work pays the settlement difference and writes the policy after the audit rather than before.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.