Test sites, staging & production

Three clear destinations

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 saved site has separate staging and production versions. Staging has a permanent hostname (NAME.staging.ironfountain.net) 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, or resetting it to the current production revision, 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.

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 are excluded from search indexing, but their links remain publicly accessible. Anyone with a link can open it. Production uses the site’s own search-indexing settings.

Temporary test sites do not follow redirects to other websites. Saving a test site to an organization enables those redirects; review their destinations before publishing.

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.

Automatic history and snapshots

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. Current staging and production revisions are always protected.

Downgrades include a 30-day history recovery window. Existing revisions, pins, and snapshots remain available to view or restore until the deadline shown in Revisions. New history follows the new plan's limits. Canceling a subscription starts this window when paid access ends, not when cancellation is requested. After the recovery window, normal retention resumes and history beyond the current plan's limits may be permanently deleted. Restoring a sufficient plan before the deadline keeps history covered by that plan. The window also applies when payment grace or complimentary coverage ends; it does not protect work you explicitly delete.

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

• Monthly: 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 snapshot lasts 30 days.

A snapshot keeps a revision available for viewing or restoration. Several snapshots may refer to the same unchanged revision. That revision remains available until all of its snapshots expire or are deleted.

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 does not delete a revision still used elsewhere. Deleting a revision is blocked while either environment, a pin, a snapshot, or an unexpired test site uses it. Retention describes available history, not guaranteed extra file storage; the site's storage allowance still applies.