Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
What would be the best approach for setting up a staging environment that also factors in custom subdomains?
For example, typically I would create an A record for "staging.mydomain.com" that points to my staging environment and an A record for "mydomain.com" that points to my production environment.
Now what to do when offering users their own custom subdomains...
user-1.mydomain.com, user-2.mydomain.com
or
user-1.staging.mydomain.com, user-2.staging.mydomain.com
What would these sort of A records look like considering SSL certs and configuration in Forge?
Would it just be easier to create a separate domain and purchase a separate SSL altogether? Like "staging-mydomain.com"?
@joerucci I would just have staging.mydomain.com point to the staging environment and program the system to recognize "staging" as the account for testing.
So...
user1.mydomain.com -> Prod server | User = 1 on Prod
user2.mydomain.com -> Prod server | User = 2 on Prod
staging.mydomain.com -> Staging server | User = 1 on Staging
Well I would also like to test the direct usage of "mydomain.com" with and without user subdomains on both the production and staging environments.
Im wondering if a multi-domain wildcard SSL is needed?
What about something like...
A record - *.staging.mydomain.com to staging (for user subdomains). A record - staging.mydomain.com to staging
A record - *.mydomain.com to production (for user subdomains). A record - mydomain.com to production.
I know I could not have a user with the subdomain "staging" on the production environment (as well as "www" or some other special words) but with that SSL could it work?
My goal is to use wildcards on the DNS settings (so I don't need to make one for each user) and then use the routing variables in Laravel to validate real user accounts from something just made up.
@joerucci So basically all you're asking is whether you'd need a wildcard SSL. Yes. If you want to secure the subdomains. You'll need a wildcard SSL. You might actually need a custom SSL in some cases. Either way, you can't secure sub domains or sub-subdomains without a higher-level SSL cert.
But do you think that approach is better then obtaining multiple domains and more standard SSL certs?
@joerucci I would advise against doing sub-sub-domains.
I would stick with what I said and make it so that staging.mydomain.com points to its own server and just uses "staging" as the known test user account on that server. I'd write the app around that so it knew when someone hit the site with that subdomain that it is a test account. I know this is limiting but that's what I would recommend in general.
Beyond that, if you really need to test account signup and full subdomain... yeah, I'd probably spring for the extra domain(s) and certs. If you use a stack like DigitalOcean and ServerPilot's Economoy account for like $15/mo, you can setup self-signed SSLs without paying for them and they work with subdomains.
Why do you advise against sub-subdomains? Wouldn’t this work as well?
I think for my purposes I will use the separate domain/ssl approach (because of my wildcard sub domain implementation).
Looks like the TLD “.dev” is available for purchase, so the domain naming isn’t too trivial.
Please or to participate in this conversation.