Built a multi-account AWS landing zone and GitOps platform for a multi-tenant clinic SaaS - identical environments, hybrid Priority/ERP connectivity, and FinOps visibility before scale-up.

Cura9

How Dcode.tech empowered Cura9 to achieve unprecedented scalability and cost efficiency.

Overview

Cura9 is a multi-tenant clinic operations platform for healthcare clinics - scheduling, patient and clinic workflows, a tenant portal, and integrations with Priority/ERP and related practice systems. Clinics rely on it day-to-day, so uptime, secure access, and predictable change matter as much as new product features.

As the product grew, the existing environment was no longer designed with enough separation, security, and operational control for production. Cura9 needed a platform that was secure, reproducible, auditable, and easier to operate, without slowing the product team.

3Environments Live
0Shared IAM Users for Platform Access

The Challenge

The main issue was architectural, not a handful of configuration mistakes. Infrastructure lived in a single Terraform codebase with no module structure or state isolation, so a change to one component could affect unrelated parts of the environment. Development, DevOps, and production shared one AWS account. Databases and administrative services were not sufficiently private. GitHub needed direct access to the Kubernetes cluster, which meant a publicly reachable cluster API and static AWS access keys. Deployments had no GitOps model, no reliable history, and no easy rollback, so it was hard to say who deployed what and when.

Identity, secrets, and audit were also weak. AWS SSO was not properly configured, credentials were handled outside a central secrets process, and there was no organization-wide audit trail. Much of the application was still internet-facing and leaned on Cloudflare Zero Trust to compensate.

⚠️
Before Dcode

Cura9 ran production in a single AWS account with a single Terraform codebase and no state isolation. Deployments were pushed directly from GitHub with static AWS keys, the cluster API was publicly reachable, and there was no GitOps history or easy rollback. Internal access to Priority environments relied on several third-party VPN tools.

Our Solution

Fixing these issues inside the live production environment would have meant changing account structure, networking, Terraform layout, cluster access, CI/CD, identity, and security controls all at once. Dcode built a new platform in a structured way and migrated workloads to it, which was safer and easier to maintain than extensive changes to running production.

The new platform separates DevOps, development, stage, and production into isolated AWS accounts with controlled permissions between them. Infrastructure is modular Terraform with isolated state, so each component changes on its own. Argo CD GitOps with ECR and AWS-native access replaced direct cluster access from GitHub, so deployments are controlled, traceable, and easy to roll back. IAM Identity Center connected to the company identity provider replaced individual IAM credentials, and organization-wide CloudTrail gave full visibility into administrative activity. Secrets are centrally managed through External Secrets instead of living in deployment pipelines.

Workloads and load balancers now stay private. Only the required entry points are exposed through CloudFront and WAF. One managed VPN gives employees and service providers access to internal resources, including Priority environments, and access is revoked in one place at offboarding. Centralized logging, monitoring, backup automation, and security controls are part of the base platform instead of being added later. FinOps work priced the monthly AWS run-rate before scale-up, with account separation so spend can be attributed per environment.

💡
AWS Well-Architected: Cost Optimization

This engagement followed the AWS Well-Architected Security and Operational Excellence pillars. Account isolation, private networking, centralized identity, and audited access reduced the attack surface. GitOps, reproducible infrastructure, and built-in observability made change predictable.

Results

  • 0 static AWS keys in CI/CD - release path uses short-lived, AWS-native access
  • Private workloads and databases - only CloudFront and WAF entry points are exposed
  • One managed access path for internal resources, with immediate revocation at offboarding
  • 100% of admin activity audited with organization-wide CloudTrail
  • Controlled deployments with rollback - every change is tracked in Git
  • Secure, reproducible, and auditable platform ready for long-term production use