A staging holds your content, your customers' data and your plugins' credentials. The interesting question is not which acronyms we can list — it is what the copy can reach, who can open it, and where the bytes travel. All three have concrete answers.
The connector asks our platform for a presigned upload URL and then writes the archive straight to object storage. The bytes go from your server to storage; we handle the paperwork, not the payload. When a staging launches, the worker pulls the archive from storage the same way. There is no point in the path where a copy of your site sits on an application server of ours.
Every request between platform and connector carries a timestamp and an HMAC-SHA256 signature over the method, path and body, checked against a per-site secret with a five-minute tolerance. The secret is stored in WordPress encrypted with AES-256-GCM under a salt generated when the plugin is activated, so it is not the same key on two sites.
A staging never receives the site's API secret. The admin-login key and the telemetry key baked into it are derived from it, separately. Someone who takes over a staging container gets those two and nothing else — not the channel to your live site, and not the keys of any other staging.
Workers authenticate to the platform with a bearer token and only ever pull work. When you password-protect a staging, only a bcrypt hash of the password reaches the worker — a compromised worker node cannot read back what you handed to a client.
Stagings sit behind a password by default, checked at the proxy before a request reaches WordPress — so a vulnerability in the site you are testing is not exposed to the internet while you test it. The one-click admin link is a signed token valid for ten minutes and exactly one use.
Security pages are where products describe the company they intend to be. Here is where this one actually stands, so you can judge it against your own requirements instead of discovering the gap later.
security@stageforge.app — a person reads it.