Cloud deployments
The runtime is a Python package and a small service, so it runs anywhere you can run a container or a function. This page shows how each deployment pattern maps onto managed cloud building blocks, and which clouds have detailed guidance today.
You deploy it; Helixor does not host it
Every cloud deployment on these pages runs in your own account. Install the runtime wheel into an image you build, and bring your own license file. No managed image, template or marketplace product is required. An AWS Marketplace listing is Planned.
Status by cloud#
| Cloud | Status | Guidance |
|---|---|---|
| AWS | Reference guidance | AWS and AWS Well-Architected alignment |
| Google Cloud | Planned | Use the generic mapping below. |
| Microsoft Azure | Planned | Use the generic mapping below. |
| Other clouds and on-premises clusters | Planned | Use the generic mapping below. |
"Reference guidance" means documented patterns and example configuration that you adapt. It does not mean a supported product integration or a certified deployment.
Mapping patterns to cloud building blocks#
| Need | Managed primitive | Notes |
|---|---|---|
| In-process runtime | Your existing container service, Kubernetes service, virtual machines or serverless functions | Add the wheel to your application image. Create one engine per process at start-up. |
| Sidecar | A second container in the same task or pod, sharing its loopback interface | Bind to 127.0.0.1, the default. Set a service token if other processes share the loopback interface. |
| Shared service | An internal load balancer or private service network with mutual TLS or identity-based authorization | Allow ingress only from the load balancer. Deny egress. |
| License file | A managed secret store with customer-managed encryption keys | The runtime reads a file path, so write the secret to an in-memory file at start-up or mount it with a secrets driver. |
| Pack artifacts | Versioned object storage with encryption and cross-account replication or copy | Promote by copying an approved object. Never rebuild after approval. |
| Container images | A private container registry with image scanning | Never put the license in an image. |
| Logs and receipts | A managed log service, exported to write-once object storage | Receipts are unkeyed. Write-once retention supplies tamper evidence. |
| Metrics | The platform's metrics service, fed from your application | The runtime exports no metrics endpoint. |
| Egress control | Private subnets, private service endpoints, firewall rules and network policy | Zero egress is a code property; enforce it here. |
| Environment isolation | Separate accounts, projects or subscriptions per environment | Use one license per environment where your agreement allows. |
| Scheduling | A managed scheduler or event rule | For the daily license-expiry check only. Never poll. |
Portable practices#
These hold on every cloud and are detailed in the pillar pages:
- License and packs are deployed as one versioned pair. Renewing a license means rebuilding the packs; see Reliability.
- Readiness checks run a real evaluation;
/v1/healthis enough for liveness. See Reliability. - Logs carry receipts, never payloads or
matched_items; see Security. - Scale with processes and replicas, about one core each; see Performance efficiency.
- Keep hosts on a trusted time source, because license validity uses the local clock.