# Test sites, staging, and production

## Three clear destinations

| Name | What it is | Lifetime |
|---|---|---|
| Test site | A temporary copy of an existing website, made before you save it to an organization. No account is required to start. | Expires one hour after the import starts. Cleanup deletes copied files and temporary records every ten minutes. Saving retires the test address immediately. |
| Staging | A saved site's permanent address for reviewing unpublished changes, such as `my-site.staging.ironfountain.com`. | No one-hour expiry. The address shows the current staging revision. |
| Production | Your published website, on its Iron Fountain address or custom domain. | Stays live until you change or unpublish it, subject to your plan. |

Start a new site directly in an organization, or save a test site to continue in staging. Imports started inside an organization also go directly to staging. Publish a reviewed revision to put it into production.

A **revision** is a saved version of the files. Its link opens that exact version, even after staging changes. Revisions follow your plan’s automatic history policy; they are not another kind of staging or a temporary test site.

Test sites and staging are excluded from search indexing. Test sites simulate forms without saving submissions; staging and retained revision links use the Staging submissions inbox. Production keeps its own forms inbox and robots policy.

## Saved site behavior

Every registered site has two independent revision pointers. Staging has a permanent hostname (`NAME.staging.ironfountain.com`) and production uses the free hostname until a custom primary domain is connected. A staging name is editable in site Settings and unique across the service. Renaming does not change content, production domains, or revision history; the previous name stops serving that site.

Saving an unpublished revision advances staging. Publishing or restoring a retained revision changes production alone. Reverting staging changes staging alone. A first direct production upload initializes staging when it is empty; later direct production uploads preserve staged work. Each environment records its own revision history. Recent revisions, pinned revisions, and automatic snapshots have separate allowances; shared content hashes prevent duplicate file storage.

`staging_url` identifies the permanent staging address, `staging_revision_id` its current revision, and `production_url` the published address (null before publication). `revision_url` opens a specific retained revision. Immutable revision links remain available until that revision is pruned. The Revisions screen has Staging and Production history tabs, independent revert controls, and an explicit Publish staging to production action.

An anonymous import has a one-hour temporary URL. Claiming immediately retires that temporary hostname, preserving the saved revision and assigning permanent staging. Import reports link to the exact imported revision; they cannot accidentally substitute the old import for the site's current staging revision. Imports into connected sites are rejected before source inspection. An incomplete migration can explicitly refresh the imported copy; another website belongs in a new site.

Staging, revision links, and test sites return `X-Robots-Tag: noindex, nofollow, noarchive` and synthetic `robots.txt` with `User-agent: *` and `Allow: /`, including unknown and expired staging/test hosts. Crawlers must be able to fetch pages and assets to read the noindex header; a blocking robots file would prevent that. These overrides apply to responses only and never change saved revision files. Missing and retired content still returns 404 with noindex. This controls search indexing for supporting crawlers, not access: test-site and staging links remain public. See [Google's noindex requirements](https://developers.google.com/search/docs/crawling-indexing/block-indexing).

Staging, revision, and test-site responses carry an `X-IronFountain-Revision` header naming the served revision; production responses omit it, so a live site never reveals the retained revision links that stay readable after a replace or unpublish. A test site follows its same-site redirect rules but not off-site ones: an address whose imported rule points to another website returns a page showing that destination as text, because an unclaimed copy has no accountable owner. Saving the site to an organization enables those redirects on its staging, revision, and production addresses.

Staging pages restrict forms and off-site API calls. Free production sites preserve their robots files. Once a custom primary domain is active, the free production hostname returns a 308 redirect preserving path and query instead of serving an indexable mirror. No public site directory exists; organization/site enumeration requires authentication.

Bunny DNS `*.staging` points at the shared Volume pull zone, which holds `*.staging.ironfountain.com` with its Bunny-managed wildcard certificate. This uses one provider hostname for all staging sites. Revision URLs use the existing platform wildcard. Bandwidth routes track both stable and immutable addresses and retain organization attribution across moves and renames.

MCP adds batched reads, paginated file lists, exact hash-checked text replacements, staging reversion, and staging-address changes. Tools report draft/publication state and explicit URLs; logs record request IDs, tool names, duration, and success without content or credentials.

## Automatic history and snapshots

| Plan | Recent revisions per environment | Pinned revisions per site |
|---|---:|---:|
| Spring | 3 | 0 |
| Flow | 20 | 10 |
| Cascade | 50 | 25 |

Pinning does not reduce recent history. A revision that appears in both environments uses one pin. Pinned revisions stay until unpinned while paid history access continues. If a paid plan change puts existing pins above the new allowance, existing pins stay protected but adding pins is blocked until usage is below the new limit. When paid access ends, Spring's policy applies: pins and snapshots end and older revisions become eligible for cleanup. Current staging and production revisions are always protected.

Flow and Cascade also include two automatic snapshot types, independently for staging and production:

- **Monthly:** a pointer to the revision in use at the start of each calendar month (UTC), retained for 12 months from that boundary.
- **Before changes:** after at least 24 hours without a revision change in that environment, the next successful save, publication, or rollback first records the previous revision. The pointer lasts 30 days. Failed writes and no-op restores do not create a session snapshot.

A snapshot is a pointer to a revision, not another copy of its files. Several monthly snapshots may reference the same unchanged revision. An old revision stays protected while any unexpired snapshot references it, even if the revision was created years ago. Monthly pointers are materialized from retained channel history during reads, writes, and cleanup; an idle site requires no duplicate content or scheduled revision uploads.

In **Revisions**, choose Staging or Production, then Recent revisions, Snapshots, or Pinned. You can view or restore a snapshot's exact revision, delete an individual snapshot, and delete unused revisions. Deleting a snapshot removes only that pointer; it is not recreated. Deleting a revision is blocked while either environment, a pin, a snapshot, or an unexpired test site uses it. Unreferenced files are removed by background cleanup, with a one-hour safety window after a revision is created or replaced. Retention describes available history, not guaranteed extra file storage; the site's storage allowance still applies.