EHR Platform

CI/CD security and cost modernization for a HIPAA enforcement

When your CI/CD pipeline becomes one of your top recurring infrastructure expenses and your deployments are still fragile, something is wrong. In a PHI-regulated environment, shared external runners don't just cost money, they create governance exposure that HIPAA compliance services will flag on first review. How do you cut costs, increase control, and improve deployment safety all at once?

sales@itsyndicate.org

Faster releases. Lower cost. Stronger security boundaries.

The US-based EHR platform we partnered with encountered an issue in its delivery pipeline. The engineering team relied heavily on CircleCI with shared runners. As product complexity grew, so did CI/CD costs, approaching $70,000 annually, while visibility into pipeline execution remained limited. For a platform handling PHI data under HIPAA, external shared runners also raised questions that the compliance team couldn't easily dismiss. The client needed to regain control over CI/CD tools and delivery infrastructure without disrupting the engineering teams that depended on them daily.

Quick facts

EHR Platform

Private medical practices in the USA

Cloud-based EMR/EHR platform for private medical practices in the USA, handling PHI data under HIPAA across scheduling, charting, billing, and telehealth.

$70K+

Cost reclaimed

Migrating from CircleCI shared runners to self-hosted runners inside Kubernetes eliminated over $70,000 in annual SaaS spend while improving execution consistency and reducing CI/CD pipeline queue times.

Kubernetes + AWS

Running CI/CD inside your own Kubernetes cluster means private execution, controlled credentials, and direct integration with internal AWS resources without paying a SaaS premium for the privilege.

"ITsyndicate transformed our most critical infrastructure component into a predictable, managed system without disrupting a single day of operations."

Michael Torres

CTO, US Healthcare EHR Platform

What we did for the EHR Platform

CI/CD pipeline audit and architecture redesign

Before recommending any tooling change, we needed to understand exactly where the cost was coming from and why the pipelines were brittle. CircleCI billing at this scale rarely reflects a single inefficiency; it accumulates from parallelism settings, caching misses, redundant steps, and over-provisioned resource classes across dozens of workflows. Our team ran a full audit of execution patterns, billing breakdowns, and YAML logic before proposing a single architectural change.

Pipeline audit and waste identification: We analyzed CircleCI usage across billing tiers, workflow execution times, and runner utilization patterns. The audit revealed a combination of over-parallelized jobs, poorly scoped caching, and conditional logic that had grown brittle over successive feature additions. We documented each inefficiency with a cost and risk attribution before the redesign began, giving the client a clear picture of exactly what they were paying for and why.
Self-hosted runner architecture design: We designed a private runner architecture that runs within the client's existing Kubernetes cluster on AWS. This eliminated dependence on CircleCI's shared runner pool, brought execution within the defined CI/CD security boundary, and enabled direct integration with internal AWS resources without exposing credentials via third-party infrastructure. We pushed back on an initial proposal to keep CircleCI for some workloads in a hybrid model. The compliance and operational overhead of maintaining two execution environments wasn't worth the convenience of the transition.

Migration to HIPAA-compliant self-hosted runners

Moving CI/CD pipeline execution from an external SaaS to internal infrastructure is a change that touches every engineering team simultaneously. It has to be done without creating a deployment freeze. We ran the migration in parallel with live production pipelines, validating the self-hosted runner behavior against existing CircleCI baselines before any team was switched over.

Deployment of self-hosted runners in Kubernetes: We deployed and configured self-hosted CircleCI runners inside the client's Kubernetes cluster, with resource limits, pod security policies, and namespace isolation aligned with the existing cluster security posture. Credentials and environment secrets were moved out of CircleCI's secrets management and into AWS Secrets Manager, accessed at runtime through IAM role-based authentication. This closed a CI/CD security gap the compliance team had flagged but hadn't previously had a path to resolve, directly improving the platform's HIPAA enforcement posture.
Pipeline standardization and YAML simplification: Alongside the runner migration, we refactored the CI/CD pipeline YAML across the main repositories. Complex conditional branching that had accumulated over the years was removed or restructured. We introduced reusable config components to reduce duplication and improve readability. The result was pipelines that were faster to execute, easier to debug, and maintainable by engineers who hadn't written them a meaningful operational improvement in a team of the client's size.

CI/CD security and HIPAA compliance: FAQ

Why do shared CI/CD tools create HIPAA compliance risk?

Because shared runners create execution source gaps that are difficult to close under audit.

In a HIPAA-regulated environment, you need to demonstrate that PHI-adjacent build processes execute within defined security boundaries, with controlled access and traceable credentials. Shared runners on external infrastructure make that demonstration harder, as you're relying on your SaaS provider's security attestations rather than your own controls.

For this client, moving execution inside Kubernetes meant CI/CD pipeline runs were subject to the same IAM policies, logging, and network controls as the rest of the AWS environment.

Did switching to self-hosted runners slow down the CI/CD pipeline?

No - execution times improved.

Shared runners introduce queue latency that scales with platform load, not with your own workload. Self-hosted runners inside the client's Kubernetes cluster had no external queue dependency, and with right-sized resource allocations, build execution times dropped.

The pipeline refactoring we conducted in parallel, removing redundant steps and improving caching, further compounded the improvement.

How do self-hosted runners strengthen HIPAA enforcement in a CI/CD environment?

They bring CI/CD pipeline execution under the same governance controls as the rest of your infrastructure.

With runners inside Kubernetes on AWS, credentials are sourced from AWS Secrets Manager via IAM roles rather than stored in a third-party secrets vault. Execution logs flow into the client's existing CloudWatch and audit logging infrastructure. Access to runner configuration is controlled through the same IAM policies governing the rest of the environment.

Each of these was a gap in the previous CircleCI shared-runner setup that required manual workarounds or acceptance of risk, and each maps directly to HIPAA compliance service requirements around access control and auditability.

How do you right-size self-hosted runner infrastructure without over-provisioning?

Start with baseline data from your existing SaaS usage, then size iteratively.

The CircleCI billing audit gave us precise data on peak concurrency, average job duration, and resource class usage across workflow types. We used this to define initial Kubernetes resource requests and limits for the runner pods, then tuned based on actual execution behavior in the first weeks post-migration.

The client ended up running the same CI/CD pipeline workload on significantly less compute than the SaaS equivalent, which implied a secondary cost saving on top of the eliminated license spend.

What does CI/CD pipeline standardization actually change day-to-day?

It reduces the cognitive load of debugging and the risk of unintended changes.

Pipelines that accumulate conditional logic over years become difficult to reason about, as a change in one branch affects behavior in ways the author didn't anticipate. For this client, we removed branching logic that had grown beyond what any single engineer could confidently trace, and replaced it with explicit, readable pipeline definitions.

Onboarding new engineers to the CI/CD tools setup became significantly faster, and the change failure rate on pipeline modifications dropped.

We’d love to hear from you

Ready to migrate critical systems without disrupting your business?

Talk to our team about your needs.