A Platform Built for the Cloud That Had to Work Without It
Several research sites operated under strict network access restrictions. No external connectivity at all during normal operation. The genomics visualization platform they were running was cloud-native by design, and that design pervaded every layer: authentication pointed to remote identity services, object storage assumed S3, inter-service calls assumed the reliability and latency of cloud infrastructure.
None of that worked inside a closed network. The sites needed the same platform, the same interface, the same visualization tools their colleagues used on connected sites. Not a pared-down version. Full parity, just self-contained.
Sequoia was brought in to make that work.
Adapting Every Layer That Assumed External Connectivity
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds and adapts software products for life sciences, healthcare, and enterprise technology companies. This engagement was an adaptation project. The platform existed and worked. The task was making it tractable inside an environment its original architecture had not accounted for.
Authentication was the first layer to address. The cloud identity service was replaced with a Keycloak instance running entirely within the site's Kubernetes cluster. Sign-in, role mapping, and group management all moved inside the local network. Each service that had pointed to the remote identity provider was updated to use Keycloak instead, and role-based access control was validated to behave identically to the cloud version.
Object storage was next. S3 was replaced with an on-premises storage layer that preserved the same access control and versioning the platform depended on. The rest of the application did not need to know the provenance of the storage it was talking to. That was the goal: swap the substrate, leave the behaviour intact.
The Kubernetes service architecture itself needed significant rework. Cloud Kubernetes environments tolerate a lot. Services can start in arbitrary order, health checks can wait for remote endpoints to respond, timeouts can be generous. None of that holds in a closed network. Startup sequencing was made explicit, health checks were rewritten for local timing, and every inter-service call that assumed external reachability was either removed or redirected to a local equivalent.
On the visualization side, IGV desktop integration and mutation signature views were completed for the on-premises environment, with local data sources confirmed to be reachable before release. Local email was configured for operational alerts. Once the deployment was stable, Sequoia produced runbooks for each stage of the process so the client could repeat installations at additional sites without needing Sequoia present for each one.
The Stack, and What Changed Between Cloud and On-Premises
The platform ran on Kubernetes in both the cloud and on-premises versions. The Kubernetes layer itself did not change. What changed was everything the cluster depended on externally, and the configuration assumptions baked into each service.
Keycloak deployed inside the cluster as the sole identity provider for the site. Handles sign-in, role mapping, and group management without any call leaving the local network. Each service in the platform was updated to authenticate against the local Keycloak instance, with access control validated against the cloud version for parity.
S3 replaced with an on-premises storage service offering the same versioning and access control the platform relied on. The services that called S3 were updated to point at the local storage layer. The intent was substitution without disruption to the rest of the application.
Inter-service calls, startup ordering, health checks, and timeout configurations reworked throughout for closed-network operation. Services start in a defined sequence. Health checks use local timing rather than cloud-tolerant defaults. No service makes an outbound call during normal operation.
IGV desktop integration and mutation signature views deployed and validated against local data sources. Local email configured for operational alerts. Runbooks written for each installation stage so subsequent site deployments can be executed by the client's own team.
One thing worth noting for teams evaluating a similar project: the Kubernetes refactor is usually where the hidden complexity sits. The list of services that make quiet assumptions about external connectivity is almost always longer than it looks at the outset. Auditing those assumptions before writing any code is what makes the rest of the work go faster.
Common Questions About On-Premises NGS Platform Deployment
Can a cloud-native genomics visualization platform be deployed on-premises in a restricted network?
Yes, though it requires replacing every layer that assumes external connectivity. Authentication, object storage, inter-service communication, and health checks all need to be adapted. Sequoia has done this for a major NGS platform, replacing cloud identity services with Keycloak, substituting S3 with on-premises storage, and refactoring Kubernetes services for closed-network operation.
What does replacing cloud authentication with Keycloak look like in practice?
Keycloak is deployed as a service inside the Kubernetes cluster. It takes over sign-in, role mapping, and group management from whatever remote identity provider the cloud version used. Each service in the platform is updated to authenticate against the local Keycloak instance. Access control is then validated against the cloud version to confirm parity before the site goes live.
How do you handle object storage in a network with no S3 access?
S3 is replaced with an on-premises storage service that matches the access control and versioning the platform depends on. The application services that called S3 are pointed at the local layer instead. The goal is that the rest of the platform does not need to change to accommodate the substitution.
What does adapting Kubernetes services for an air-gapped environment involve?
Startup ordering needs to be made explicit, health checks need to use local timing rather than cloud-tolerant defaults, and every inter-service call that assumed an external endpoint needs to be found and redirected. The audit phase, before any code changes, is where you find out how many quiet assumptions the services were making. That list is usually longer than expected.
Can IGV be integrated into an on-premises genomics deployment?
Yes. IGV desktop integration and mutation signature views were part of the on-premises deployment Sequoia delivered. Both work inside a closed network provided the data sources they reference are local. Local email configuration for operational alerts was included in the same deployment.
What kind of life sciences companies does Sequoia Applied Technologies work with?
Sequoia Applied Technologies is a Santa Clara, California software engineering firm that works with product companies in life sciences, genomics, healthcare, cleantech, and enterprise software. Engagements include on-premises and cloud deployments, EHR integration, embedded systems, and production software delivery.