How I am using Docker Compose for focusanalyze

The decision

For FocusAnalyze, I am intentionally not starting on Kubernetes.

The plan: run the stack with Docker Compose on an EC2 instance, sized and operated to support on the order of ~100 customers, then revisit orchestration when the failure modes demand it.

This is not anti-Kubernetes. It is pro-matching complexity to reality.

Why Compose wins early

Kubernetes shines at multi-node scheduling, rolling fleets, and platform multi-tenancy. Early FocusAnalyze needs something else:

• One coherent environment I can SSH to and reason about
• Fast iteration on app + worker + db + reverse proxy
• Predictable cost
• Ops I can do alone without a platform team

Compose gives me a readable docker-compose.yml: services, volumes, networks, restart policies. Enough control plane for this stage.

Target shape on EC2

Rough layout:

• EC2 — application host (start vertical; scale instance class before cluster drama)
• Docker Compose — web, api, worker, db / redis as needed, caddy or nginx
• EBS volumes — durable data for Postgres and artifact storage (or S3 for large blobs)
• Backups — automated snapshots + logical DB dumps
• TLS + domain — terminate at the proxy
• CI — build images, pull on host, compose up -d with healthchecks

Multi-tenant isolation at this stage is mostly application-level (auth, row-level tenancy), not one-namespace-per-customer.

How ~100 customers fits

“100 customers” is a capacity and support story, not a vanity metric.

Assumptions I design around:

• Usage is bursty, not hyperscale streaming for everyone at once
• Heavy jobs go to a worker service with concurrency limits
• Large artifacts live in object storage; the instance is not a petabyte NAS
• Rate limits and QC queues protect the box from one noisy tenant

If concurrent real-time sessions explode, that is a signal to split workers or move to a managed orchestrator — not a reason to start there.

What I give up (for now)

• Fancy multi-AZ pod rescheduling
• Per-service horizontal autoscaling out of the box
• A marketplace of operators and CRDs

What I keep: sleep, debuggability, and money.

Migration path (when Compose stops being enough)

I will reconsider Kubernetes (or a managed container platform) when:

1. A single VM cannot meet latency or CPU for peak concurrent sessions
2. We need independent deploy cadence across many services owned by more people
3. Compliance / isolation requires stronger network and tenancy boundaries
4. Downtime from host upgrades becomes unacceptable

Until then, Compose is the product strategy: ship FocusAnalyze, measure real load, then buy complexity with evidence.

Practical tips that matter

• Pin image digests in production; do not float :latest
• Healthchecks + restart policies > hope
• Separate data volumes from container lifecycle
• Document recovery: “EC2 dies tomorrow — what is the exact restore path?”
• Keep a staging compose file that mirrors prod topology

Closing

Why not Kubernetes? Because FocusAnalyze’s bottleneck is still product clarity and scientific trust, not cluster scheduling. Docker Compose on EC2 is how I stay close to the metal and the users while aiming at the first hundred customers.

When the system outgrows the box, I will write the sequel — with traffic graphs, not vibes.