ObjectOSEnvironments
Production and development environments on ObjectOS Cloud — who gets which on each plan, creating one, and what suspend, archive, restore and delete each do to its data.
An environment is one running copy of ObjectOS with its own database, files, apps and address. Your organization's apps live in environments, and your team signs in to an environment to use them. On ObjectOS Cloud there are two kinds.
| Production | Development | |
|---|---|---|
| How many | Exactly one per organization, on every plan | Paid plans only: two, plus one per AI seat, shared across the organization |
| Address | Your organization's slug on the platform domain; can carry your own domain | A fixed address of the form dev-<id>, assigned by the platform; never a branded subdomain or your own domain |
| Idle | Never archived for inactivity | Archived automatically after 7 days without use |
| What it is for | The apps your team uses | Building and trying changes before they reach production |
The first environment an organization creates is its production environment; every one after it is a development environment.
Who gets which
Free: one production environment, nothing else. You build directly in
production. Creating a second environment is refused with
403 DEV_ENV_PLAN_LOCKED, and the console offers the upgrade instead.
Team and above: production plus a pool of development environments. The pool is two development environments plus one for each AI seat the organization pays for, counted across the whole organization. Development environments are covered by the seat price; they never add a line to the bill. On a paid plan the usual flow is to build in a development environment, then publish it as a package and install that package into production.
Whether development environments exist at all is the plan's decision (ruled on cloud#1252); the one production environment is the same on every plan.
Create an environment
On Environments, choose Create Environment and give it a name; the platform assigns the address. The production environment's address can be changed later with Change Hostname (Domains); a development environment keeps the fixed address it was given. A new environment starts in Provisioning and turns Active when its database is ready.
To enter an environment, choose Open. It opens the environment's own console in a new tab, signed in as you.
The environment page
Each environment has a page with two tabs.
- Overview — its address, status, plan and type, the apps installed in it, and its access settings. A collapsed line, Features that need a higher plan, counts what the current plan does not include and lists them when opened.
- Settings — every action, in five sections: Apps, Plan and billing, Name and domain, Access and sign-in (including AI agent access) and Lifecycle and danger zone.
Actions that change an environment are offered to the organization's owners and admins.
Lifecycle
| State | What it means | Your data |
|---|---|---|
| Active | Serving requests | — |
| Suspended | All runtime traffic is blocked until you resume it | Kept |
| Archived | Removed from active views; it no longer starts on a visit | Kept until the retention window ends, then deleted |
| Failed | Provisioning did not complete | None was created |
Suspend and Resume. Suspending blocks every request to the environment, from people and from integrations alike. Nothing is deleted, and Resume brings it back as it was.
Archive and Restore. Archiving takes an environment out of use and starts its retention clock. Restore brings it back within that window; it starts again on its next visit.
Delete. Deleting is a two-step act, so one click can never destroy data:
- An environment that is not archived yet is archived, even if you asked for permanent deletion.
- Deleting an archived environment with Delete permanently if already archived checked destroys its database and all its files at once, with no recovery.
Deleting the production environment also asks you to check Force-delete the production environment. An environment whose provisioning failed holds no data and is deleted at once.
How long an archived environment is kept
| How it was archived | Kept for |
|---|---|
| By you (Archive, or the first step of Delete) | At least 30 days; 90 days on Business, a year on Enterprise |
| Automatically, a development environment idle for 7 days | The plan's window: 30 days on Team, 90 on Business, a year on Enterprise |
The environment's owner is warned shortly before an archived environment is deleted, so there is time to restore it. After the window it is deleted for good, with its database, files and domains.
Idle development environments
A development environment that nobody has visited or built in for 7 days is archived automatically. Both using the environment and developing in it (publishing, installing, editing packages) count as activity. The production environment is never archived this way.
After a downgrade to Free
A downgrade is not retroactive. Development environments the organization
already runs keep running: they are not suspended or archived by the
downgrade. What Free refuses is adding one: creating a development
environment, or restoring an archived one, answers 403 DEV_ENV_PLAN_LOCKED
until the organization upgrades again. An archived development environment is
then kept for Free's window, 7 days. (Ruled on
cloud#2253 and
cloud#2204.)
Next
- Plans and AI Seats — what the paid plans add.
- Storage and Limits — the per-environment storage allowance.
- Apps — install, update and publish apps in an environment.
Organization and Members
Your ObjectOS Cloud organization — its slug, the cloud console, inviting members, the five membership roles, and why sign-in lives in the cloud rather than in an environment.
Plans and AI Seats
The ObjectOS Cloud plans — Free, Team and Enterprise — the AI seat as the only paid seat, how to upgrade, and where the console shows what your plan leaves out.