FIG. — Staging
Staging Environments — Test Before You Go Live
Every project hosted on Edznet includes a full mirror staging environment as standard. Test before you go live — same PHP stack, isolated database, password protected, on-demand sync from production.
◉staging.yourdomain.com
Test · Isolated · Safe
→ deploy()
◉yourdomain.com
Live · Monitored · Stable
// Nothing reaches production without going through staging first.
What's Included — Full Mirror
Your staging environment isn't a stripped-back demo instance. It's a complete mirror of your production stack — same PHP version, same database engine, same caching layer, same server configuration.
Identical Server Stack
Same PHP version, OPcache config, Nginx rules, and Redis setup as production. If it behaves on staging, it will behave live. No configuration drift, no environment surprises.
Isolated Database
Staging runs its own database — a copy of production at the point of sync, completely isolated. Test data-changing operations, migrations, and schema updates without touching a single live record.
Password Protected
Staging environments are locked behind HTTP authentication by default. Your work-in-progress stays private — visible only to you and anyone you choose to share the credentials with.
On-Demand Sync
Need staging to reflect the current state of production? A sync pulls a fresh database and file snapshot across so you're always testing against real, current data — not a months-old copy.
Controlled Deployment
When you're happy with what's on staging, deployment to production is a managed, deliberate step — not an accidental overwrite. Changes move when you're ready, not before.
Included on Every Plan
Staging isn't an add-on or an upgrade. Every project hosted on Edznet managed infrastructure gets a staging environment as standard. It's part of how we build and maintain every project.
How It Works
Whether it's a new feature, a plugin update, or a significant code change — everything follows the same safe path before it reaches your users.
01
change_on_staging()
All development, updates, and modifications are made on staging first. New code, plugin updates, configuration changes — nothing touches production directly.
02
test_against_real_data()
Because staging is synced from production, you're testing against a realistic dataset. Edge cases that only appear with real content get caught here — not on live.
03
review_and_sign_off()
You review the changes on staging and confirm they're working exactly as expected. No time pressure, no users watching. Sign off when you're genuinely satisfied.
04
deploy_to_production()
Once signed off, changes deploy to the live environment in a controlled, managed step. Predictable, documented, and reversible if anything unexpected arises.
What Breaks Without a Staging Environment
The risks of skipping staging aren't theoretical. Every item on this list is something we've seen happen to projects that didn't have a safe place to test.
💥
live_updates_break_things()
Updating a plugin or module directly on production without testing is one of the most common causes of live site outages. A single incompatibility can bring a site down in front of real users. Staging catches it first.
🗃️
db_migrations_gone_wrong()
Schema changes, data migrations, and WHMCS upgrades can behave differently in production than expected. Running them on a real data copy in staging first means you know exactly what will happen.
🎨
design_changes_need_signoff()
Clients and stakeholders need to review changes before they go live. Staging gives them a real URL to visit and approve — no more looking at screenshots or taking a developer's word for it.
🔗
integration_failures()
API integrations, payment gateway connections, and third-party webhooks can behave unexpectedly when code changes. Test the full integration chain on staging before it affects a live transaction.
// The rule we follow on every project: If it hasn't been tested on staging, it doesn't go live. No exceptions — not for small changes, not for "quick fixes", not under time pressure.
// note on WHMCS WHMCS updates in particular should always be tested on a staging instance first. Major version upgrades can break custom modules, hooks, and third-party integrations in ways that aren't visible until you run the upgrade. We maintain staging environments on all WHMCS-hosted projects specifically to absorb this risk.
Technical Specification
No hand-wavy "it's a copy of production." Here's exactly what's included in every Edznet staging environment.
◉// staging_spec.config
PHP Version
Matched to production · PHP 8.x · OPcache · PHP-FPM
Database
Isolated copy · MariaDB/MySQL · No live writes
Web Server
Nginx · SSL · HTTP/2 · Matching production config
Caching
Redis available · Typically disabled on staging
Access Control
HTTP auth by default · IP restriction available
Email
Outbound intercepted by default · No staging emails to real users
Sync
On-demand from production · DB snapshot · File sync
Included With
All Edznet managed hosting plans · No extra cost
Frequently Asked Questions
What exactly is a staging environment?
A staging environment is a full copy of your live website or application — same codebase, same database, same configuration — running in an isolated, password-protected space. It lets you test changes, updates, and new features before they go live, without any risk to your production site or its data.
How do I access my staging site?
Every staging environment is given its own URL (typically staging.yourdomain.com) and is locked behind HTTP authentication. We provide you with the access credentials when your environment is provisioned. You can share these with team members, clients, or stakeholders as needed.
Can I sync production data to staging?
Yes. Staging environments include on-demand sync from production. A sync pulls a fresh snapshot of the production database and files into staging so you're always testing against current, realistic data. Syncs are triggered on request — never automatic — so you control when data moves between environments.
Is staging included in all hosting plans?
Yes. Staging is a standard part of every Edznet managed hosting plan. It is not an add-on, an upsell, or a premium feature. Every project we host gets a staging environment as part of how we build and maintain software.
Can clients review changes on staging before they go live?
Absolutely. In fact, this is one of the primary use cases for staging. Share the staging URL and credentials with your client — they can review the changes in a live browser, on real data, and give informed sign-off before anything reaches production.
Does staging cost extra if I need more resources?
Staging mirrors your production allocation at no additional cost. If your project requires a staging environment with significantly more resources than the standard mirror — for load testing, for example — we can discuss options, but for normal development and testing workflows, the included staging environment is sufficient.
Ready to Get Started?
If you're building something that needs to be reliable — whether that's a WHMCS module, a WordPress platform, or a custom PHP application — talk to us about hosting it the right way from day one.
start_a_project()
Every hosted project starts with staging built in. Fill in a brief and we'll get back to you within one working day.
→ Start a Project Brief