Manage Website Environments and Deploys

Select the Website first, then select the Website Environment before changing runtime state.

Website Environments isolate deployable or mutable instances of the same Website. Names such as production or staging describe their purpose; they do not create a universal promotion workflow. The available actions depend on Website Runtime and the capabilities TMXIO reports for that Website.

WordPress

Use Environments to create or select the WordPress instance you intend to manage. Confirm the environment label and public URL before updates, restore, or configuration work.

Static HTML

Static HTML Websites expose Environments for environment-specific settings such as SFTP, but do not expose Deploys. Publish static files through the Website’s configured hosting workflow, then verify the public response. Use Backups for files-only recovery points.

Node.js

Use Deploys for application revisions and Environments for runtime instances. Confirm configuration and secrets are present in the destination before moving traffic.

When you create a staging or development environment, TMXIO copies production’s current runtime settings and automatically queues its latest confirmed-healthy release as the first deployment. Git Websites reuse the exact commit and artifact Websites reuse the exact retained release; TMXIO does not resolve a branch again. Creation stops without leaving a partial environment if production has no confirmed-healthy release, a deployment is still running, or the release can no longer be copied.

The new environment does not receive production environment variables, secrets, managed databases, database files, or Data Directory contents. Add its isolated configuration and data before relying on the first deployment. Later production changes do not automatically update the environment.

You can transfer a healthy artifact release between production, staging, and development. Data Directory copying and runtime-setting overwrites are separate options, both off by default. A completed transfer can carry an application-health warning; read the result and verify the destination before relying on it.

Bind the application to process.env.PORT. TMXIO allocates and injects this value; the concrete port is platform-managed and is not shown or configurable as an environment variable.

PHP

Use Environments to select the PHP version, public root, routing mode, health path, and optional bounded release command. TMXIO owns the Nginx and PHP-FPM templates; use only the provided server-configuration slots for Nginx customizations. Use Deploys for immutable application artifacts and rollback.

A newly created PHP Website opens directly in its production environment so you can copy the artifact upload token. It does not enter WordPress provisioning. The Website begins serving application traffic after its first artifact deploy completes.

PHP settings for WordPress and PHP

Hosted WordPress and PHP Website Environments expose optional PHP-FPM overrides for the PHP memory limit, maximum input variables, OPcache memory, and OPcache interned strings memory. Empty fields inherit platform defaults; existing environments continue to inherit those defaults until you save an override.

An override applies only to the selected Website Environment. Saving an effective change reconciles that environment’s PHP-FPM pool and may briefly interrupt in-flight PHP requests. Use Use all platform defaults to clear every override and return the environment to inherited policy.

Verify a change

1. Confirm the selected Website Environment.
2. Record the previous revision or restore boundary.
3. Run the runtime-specific action once.
4. Follow the operation until it reaches a terminal result.
5. Verify the public domain and customer-critical paths.
6. Roll back with the runtime-specific control if verification fails.

Do not infer success from a queued or running state. The operation must finish and the public behavior must be checked.