Is this self-hosted AWS architecture ready for production?

0
0
Asked By MellowPine47 On

I'd like feedback on a self-hosted AWS setup and advice on what to improve before using it in production. Currently, I have two React apps running together on one frontend EC2 instance, two Go APIs running together on a backend EC2 instance, and MySQL, Redis, Vault, Keycloak, and MinIO all sharing a single core-services EC2 instance. Superset runs on its own EC2 instance, while Airbyte runs through abctl with a Kind/Kubernetes environment on another.

Everything is deployed on EC2 using Docker Compose except Airbyte. I'm particularly concerned about whether the stateful services should be separated, whether MySQL and Redis should move to managed services such as RDS and ElastiCache, and whether Docker Compose is still appropriate or if Kubernetes would be worthwhile.

For deployments across multiple servers, I'm comparing Dokploy, Coolify, and Komodo. I'd like something lightweight, stable, easy for a small DevOps team to maintain, preferably fully open source, with multi-server support, strong Docker Compose integration, GitHub-based automatic deployments, rollbacks, logs, and environment-variable management. What would you change if this were your production environment?

3 Answers

Answered By CedarFox21 On

You haven’t necessarily made a bad design choice, but I’d separate stateful and stateless workloads before changing orchestration. Keep the React and Go services on Compose for now, while giving the database, cache, identity, secrets, and storage services clearer failure boundaries. Managed RDS and ElastiCache are sensible if the budget allows; the cost is often justified by automated backups, point-in-time recovery, maintenance, and failover. I’d also make sure MinIO has a real backup and recovery plan rather than relying on the EC2 volume alone.

Answered By QuietHarbor8 On

The main risk isn’t Compose versus Kubernetes; it’s putting MySQL, Redis, Vault, Keycloak, and MinIO on one machine. A disk failure, out-of-memory event, or bad update could take out your database, authentication, secrets, and object storage at the same time. I’d move MySQL to RDS and strongly consider ElastiCache for Redis so backups, patching, and high availability aren’t entirely your responsibility. Then isolate Vault and Keycloak from the general data services. For a setup of this size, Compose is still reasonable, and Kubernetes would add a lot of operational complexity without much benefit unless you need substantial autoscaling or many independently deployed services.

Answered By OrbitingNook6 On

For a small team already comfortable with Compose, Dokploy sounds like the best fit of the three based on the experiences described here. It has been smoother for multi-service deployments and GitHub-triggered releases. Coolify offers more features, but its multi-server behavior and rollback experience can become frustrating as the number of Compose projects grows. Komodo may be worth evaluating, though its documentation and ecosystem appear less mature. Whichever tool you choose, keep production deployment definitions in version control and test restores and rollbacks regularly; the platform itself shouldn’t become a single point of failure.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.