The Infrastructure behind VELOX

Kubernetes, Terraform, and Deployment without Vendor Lock-In

VELOX runs on a modern, cloud-native infrastructure stack managed entirely through Infrastructure as Code. A core design requirement from day one: the platform must be deployable on any major public cloud, on Swiss-local providers, and on-premise — without forking the codebase or maintaining separate infrastructure definitions per environment.

This post walks through the architecture layer by layer.

‍

No vendor lock-in: The Role of Terraform

All VELOX infrastructure is defined in Terraform. Every environment — development, staging, production — is provisioned from the same versioned codebase, parameterised per customer and target deployment. This gives us consistency across environments, full change history, and the ability to onboard a new customer without manual configuration drift.

More importantly, it's what makes VELOX deployment-agnostic. We maintain battle-tested configurations for AWS and Azure. For customers with Swiss data residency requirements, we support providers such as Exoscale. For customers who can't or won't run on public cloud at all, we support on-premise Kubernetes clusters, i.e. the same Terraform modules, with provider-specific implementations underneath.

The same guarantees apply regardless of where you run: consistent networking, security policies, secrets management, and access controls, all of which are versioned and reviewed in the same way as application code.

‍

Container Orchestration: Kubernetes

VELOX is a microservices platform. Kubernetes handles scheduling, scaling, and availability of all services. On AWS this is "Elastic Kubernetes Service" (EKS) with managed node groups. On Azure it's "Azure Kubernetes Service" (AKS). On-premise it runs on self-managed clusters. The application layer is identical across all of these. Kubernetes abstracts the underlying infrastructure from the workloads running on top of it.

Horizontal pod autoscaling adjusts capacity based on real traffic. In ecommerce, load is spiky and seasonal. Kubernetes handles peaks without manual intervention and scales back down to avoid paying for idle capacity. Rolling deployments and health checks ensure updates ship without downtime.

Traffic routing and TLS termination are handled at the ingress layer. On AWS this is the ALB Ingress Controller with an Application Load Balancer; on other deployments, equivalent ingress controllers are substituted without changes to the application configuration.

‍

Network Architecture

The network layer separates public and private subnets clearly. Sensitive workloads, such as databases and internal services, are never exposed to the public subnet.

• Inbound and outbound traffic flows are controlled at the gateway layer
• Security groups and network policies enforce least-privilege access between tiers
• A WAF (Web Application Firewall) sits in front of public endpoints, handling bot mitigation, rate limiting, and common attack patterns

On public cloud this maps to provider-native constructs (VPC, Internet Gateway, NAT Gateway). On-premise, equivalent segmentation is implemented via network policies and ingress configuration within the Kubernetes cluster.

‍

Data Layer

VELOX uses purpose-fit data stores rather than a single general-purpose database:

• PostgreSQL or MySQL for transactional data: orders, customers, payments. On AWS this is RDS. On-premise this runs as a managed PostgreSQL/MySQL instance outside the cluster or as a Kubernetes-native deployment.
• MongoDB-compatible document store for flexible product catalogues and content structures. On AWS this is DocumentDB; on-premise it's MongoDB directly.
• OpenSearch for product search, filtering, and faceting — tuned for the query patterns ecommerce search generates.

Each database tier is isolated from public access. Credentials are managed through a secrets backend: Secrets Manager on AWS, Vault or equivalent on-premise.

‍

Storage, CDN, and DNS

Product images, media assets, and backups require object storage. On AWS this is the Simple Storage Service S3. On-premise or on Exoscale, S3-compatible object storage (such as MinIO or Exoscale Object Storage) is used — the application integration is identical since both expose the S3 API.

Content delivery via CDN is cloud-specific by nature. On AWS, CloudFront distributes assets globally. On-premise or private cloud deployments typically front assets through a CDN layer at the network edge, or through a reverse proxy with caching if global distribution isn't a requirement.

DNS and TLS certificate management follow the same pattern — provider-native where available, self-managed where not.

‍

Messaging and Async Processing

Background tasks (order confirmations, inventory updates, notification dispatch) run asynchronously to keep the request path lean. On AWS this is SQS or EventBridge. On-premise, equivalent message brokers (such as RabbitMQ or Kafka) slot into the same integration points.

‍

Observability

Logs, metrics, and traces are collected across the full stack. On AWS, CloudWatch and optionally X-Ray handle this. On-premise deployments typically use a self-hosted observability stack: Prometheus, Grafana, and Loki are the common choices and are supported out of the box.

‍

Security and Identity

All inter-service communication is authorised through scoped, short-lived credentials — no long-lived secrets embedded in application config. On AWS this is IAM with IRSA (IAM Roles for Service Accounts), so each Kubernetes workload gets its own role with exactly the permissions it needs. On-premise, this maps to Kubernetes service accounts combined with Vault or a comparable identity and secrets platform.

Access policies follow least-privilege throughout.

‍

Deployment Options Summary

The application layer is the same across all rows. What changes is the infrastructure provider implementing each capability. Terraform manages this mapping.

Click here to learn more: e-commerce with microservices.

‍

If you want to go deeper on a specific deployment target, or discuss how this maps to your existing infrastructure and constraints, we're happy to get into the details.