Post #2751351

2026-03-29 07:21 UTC

Had a consultation with claude: ddev would be a solution, but with docker-compose I could use a shared mysql database server and save RAM. Therefore the leaner stack would be: n8n, docker compose on a Hetzner CAX31 „The 16GB RAM matters — each Craft preview stack (PHP + nginx + MySQL + Redis) eats roughly 500MB–1GB idle, so 8GB limits you to ~4 concurrent previews, 16GB gives you ~8–10.“ And my question: „Does anybody use such a Setup with automatic / ephemeral preview environments? Why is it not common in the craft cms community?“ #craftcms #php #ai #devops #docker

Replies (3)

@zhaph@fosstodon.org 2026-03-29 07:44

@mandrasch@social.tchncs.de (Limited Craft, but lots of CMS experience) I feel it's the whole "seeded database with the current set of content changes required" - i.e. you often don't want a shared DB for different branches because you'll quickly end up with issues with missing/stale field/template/what-have-yous in there.

Open ##2751352
@luceos@fosstodon.org 2026-03-29 09:48

@mandrasch@social.tchncs.de not a craft user either, but ran point on many customer targeted website development projects. In the end what made the most sense for staging was to combine features into one release. Staging in the end is meant as a last review environment for the client, not the developers. Allowing your clients to aok on the staging branch before being released reduces complexity and retains cyclic development patterns. This also means you only need one staging environment, hence forge or cicd

Open ##2751354
@Crell@phpc.social 2026-03-29 13:57

@mandrasch@social.tchncs.de Upsun (formerly Platform.sh) has been doing ephemeral PR environments for like 15 years. With fast prod clones of the database. Works with basically any app.

Open ##2751358