Best practice for isolated, highly-available dev/staging/production environments across 2 Angular + 1 Laravel repos
07:17 17 Jul 2026

I have 3 separate repositories that make up one product:

  • frontend-admin (Angular)

  • frontend-client (Angular)

  • backend-api (Laravel)

I need to deploy all three across dev, staging, and production, with two hard requirements:

  1. Isolation — a bug or bad deploy in dev/staging must never be able to touch staging/production data, secrets, or traffic.

  2. High availability — production specifically needs to survive a single server/instance/AZ failure with no downtime.

Questions:

  • Should each environment be a fully separate cluster/VPC, or is namespace-level isolation (e.g. separate Kubernetes namespaces, separate .env files, same infra) considered "good enough" in practice?

  • For 2 Angular apps + 1 Laravel API, is it standard to run them as 3 separate deployable units (e.g. 3 containers/services) even though they share one product, or should the Angular apps be built as static assets served via CDN/nginx rather than containers at all?

  • For the Laravel API specifically, what's the recommended HA setup (e.g. multiple app instances behind a load balancer + managed DB with replica/failover + Redis for sessions/queue)? Is a single "app server + DB server" pair ever acceptable for staging, or should staging mirror production's HA topology too?

  • Any pitfalls when 3 repos need to be versioned/deployed together (e.g. API contract changes) vs. independently?

Stack so far: Laravel 10, Angular 17, considering Docker + Kubernetes (or plain Docker Compose + a load balancer if K8s is overkill for our team size). Team is small (3 devs), so also open to hearing if K8s is overengineering here.

php angular laravel docker kubernetes