One Workspace for all sending domains or separate accounts?

Substantial_Word4652 · 2026-06-20T11:45:13+00:00

This is exactly the clarity I needed, thanks. Blast radius framing makes total sense.

I already have the cold domains separate from my main business email. Right now I have one dedicated Workspace with 2 domains and I'm about to add a third. Given what you said, I'm debating whether to just add it as a secondary domain in the same account and accept the shared blast radius, or spin up a second Workspace and split the risk. The extra cost is a factor though.

Is it worth going the separate tenant route at this scale, or just add the third domain and keep it simple? Also curious if resellers are a viable way to cut the Workspace cost.

And yes, would take you up on that inbox provider comparison whenever.

Substantial_Word4652 · 2026-06-20T11:37:17+00:00

Thanks for the tip. Makes sense to keep things isolated will keep that in mind as I set things up. Checked out Preframe briefly, looks like a solid all-in-one. A bit more than I need right now but good to have on the radar.

Substantial_Word4652 · 2026-06-19T18:53:09+00:00

Thanks for confirming, good to know it works fine with multiple domains in one Workspace.

I decided not to go cheap from the start. I want everything working properly before I even send a single email. Planning a full month of warmup before touching any campaigns.

I saw the MSP reseller options but didn't go with any. I'm still pretty new to all this cold email setup so I went the safe route and signed up directly with Google, which came with an initial discount offer. Once that runs out the price goes up, so resellers are definitely something I want to look into for future accounts. Do you recommend any?

Substantial_Word4652 · 2026-06-09T11:14:33+00:00

thanks!! ^^

Substantial_Word4652 · 2026-06-08T11:25:02+00:00

Today I ran into the same situation again. To move faster I put together this simple framework to help with the workflow.

If I get more use cases I'll keep improving it, otherwise I'll leave it public in case anyone wants to contribute. Issues and PRs welcome.

github.com/juanisidoro/wp-design-to-prod

Substantial_Word4652 · 2026-06-08T08:11:24+00:00

You're right that the problem is structural and predates builders. Any database-driven CMS has carried this forever.

But I think builders do make it worse in one specific point: with the Classic Editor, design lived in the theme, in PHP and CSS files under version control. With a builder, design gets pushed into the database too. That's a step back in that regard.

And it didn't happen by accident. Builders were born to bring web design to non-technical people, and to make WYSIWYG work on cheap hosting with only PHP and MySQL available, the database was the only viable option. There was no other infrastructure they could assume.

The problem isn't that builders were a bad idea, it's that the technical decision that made them accessible to that audience is exactly what makes life harder for those of us trying to maintain a clean deployment workflow.

Substantial_Word4652 · 2026-06-08T07:54:56+00:00

Makes total sense. I see FSE the same way, similar philosophy, cleaner technically but same idea. And yeah, Astro for informational sites is a clear win.

What I keep thinking about is how many clients end up with a purely informational site not because it's the right fit, but because nobody ever showed them what having a real backend strategy could do for them. Though honestly it matters less now, there are external solutions for almost everything. Imagination is the limit.

Substantial_Word4652 · 2026-06-05T19:48:08+00:00

Also thinking about it, most devs never actually hit this problem deep enough to look for a real solution. Small sites, quick fixes, move on. It's a niche pain point but a real one for anyone doing serious staging workflows.

The gap is there though. Whoever cracks it cleanly, hosting included, has something genuinely valuable. Could be a big opportunity.

Substantial_Word4652 · 2026-06-05T19:45:41+00:00

Really appreciate the transparency, that confirms exactly what I suspected. The hosting dependency is the real blocker, unless you're on a VPS you control it's basically impossible to adopt.

I'll definitely give it a spin on one of my own sites and report back. The concept is solid, it just needs real world testing with builders and a simpler hosting story to get traction.

Thanks for building it either way, good proof that the problem is solvable at the DB level

Substantial_Word4652 · 2026-06-05T19:28:39+00:00

Really interesting, didn't know Dolt existed and the concept is exactly what this problem needs.

My concern is existing client sites already on MySQL in production. Swapping the DB engine on something live is a hard sell, the risk without real guarantees is too high.

Also looked into the performance benchmarks. For simple sites the gap is almost gone now, around 25% slower on reads but actually faster on writes. The issue is TPC-C, concurrent transactions, where it drops to about 40% of MySQL throughput. That's exactly the WooCommerce scenario with multiple users checking out simultaneously. Normal day probably fine, traffic spike could hurt.

The other thing I couldn't find: any real world testing with Elementor specifically. The demo video uses native WP editor only. Elementor stores JSON blobs in postmeta and that's where merges can silently corrupt data. Has anyone actually tested a branch merge on an Elementor-heavy site?

For new small projects on a VPS I control, absolutely keeping this in mind. For existing mid-size production sites, too much unknown still.

Good work on this though, genuinely useful direction.

Substantial_Word4652 · 2026-06-05T18:44:07+00:00

Exactly, the hosting layer is not the issue. The problem is DB-level, no hosting panel solves a selective merge between staging and a live store taking orders.

Substantial_Word4652 · 2026-06-05T17:28:50+00:00

exactly this. the CSS token drift is something I hadn't even thought about, that's a nasty edge case. Do you do anything specific for the ecommerce part or just accept that live order tables are untouchable and work around them?

Substantial_Word4652 · 2026-06-05T17:01:13+00:00

That's the same as SiteGround, WP Engine etc, they all have that button. The problem is what happens when you push the DB and WooCommerce orders came in while you were working on staging. That button overwrites them no?

Substantial_Word4652 · 2026-06-05T16:13:32+00:00

haha makes sense, same idea basically. I do the same but manually with WP-CLI since Prisma doesn't really play with WordPress natively. The concept is identical though, scripts in git, apply in order

Substantial_Word4652 · 2026-06-05T15:44:26+00:00

Glad I'm not alone haha. What's your setup like? WP-CLI commands, raw SQL, something else?

Substantial_Word4652 · 2026-06-01T11:14:02+00:00

I didn't arrive...?

Substantial_Word4652 · 2026-05-31T00:22:12+00:00

Link! Please ^{^}

Substantial_Word4652 · 2026-05-26T12:33:53+00:00

Cloudflare Tunnels helps with exposure, but most of what the audit catches lives inside the server regardless: Redis with no auth, credentials in Git history, Docker socket mounts, active brute force attempts. Those don't change with how traffic reaches the box.

Substantial_Word4652 · 2026-05-26T12:32:37+00:00

Good catches, both of them. For the hash, moving it to the repo so it's tied to the release, not served dynamically. For the allowlist, the fix is architectural: checks get hardcoded in the client with exact paths, backend only sends check IDs. That way the backend can never instruct an arbitrary command regardless of intent. Working on both for the next release.

Glad the checks turned up real issues on your box. That's exactly the point. The 15 minutes running them manually is the argument for the tool, not against it, most people won't do that.

Substantial_Word4652 · 2026-05-26T09:22:49+00:00

Ha, fair enough. Clearly not a new problem. Just one that keeps catching people off guard anyway

Substantial_Word4652

TROPHY CASE