Customer-controlled cloud
DESIGN ONLY
The runtime deploys inside the customer's own account, so evidence and keys never leave their boundary.
No customer deployment has been performed.
Deployment & assurance
Choose a pilot boundary →
See the Control Tower →
Inspect the evidence →
One assurance runtime. Your environment.
One runtime, one evidence contract. Run it in your cloud, on-premises or offline; your data, signing keys and decision records stay inside the boundary you control.
Best first route: choose one AWS or local workflow, run it in shadow mode for 30 days, and leave with a signed evidence pack another reviewer can verify. Azure and Google Cloud can follow when a buyer needs that boundary.
Where the runtime belongsChoose the boundary first.
Run it where the risk lives.
Customer infrastructure, private cloud or a disconnected environment can host the same assurance runtime and evidence contract.
The deployment adapter changes; the decision semantics do not.The Control Tower stays consistent.
A bounded request is checked against the rule and evidence available in that environment, then routed to continue, review, stop or abstain.
The walkthrough is illustrative; production validation is environment-specific.Evidence stays with the decision.
Signing keys, decision records and replayable EvidencePacks remain inside the boundary your company controls.
AWS is the current reference evidence; other targets remain design or validation work.Your environment / Declared boundary
Place each permission where it belongs.
Explore the identity, evidence and action boundary to qualify for your environment.
Select an illustrated object to inspect its role.
01 / 03
Declare who can see and request the work.
Map organisation membership, access to records and the requested workload before integration.
Environment-specific access reviewConditions & scope
Review workspace access ↗Tenant isolation and enterprise operating guarantees require evidence for the exact deployment.
Pick a boundary. Read the evidence state.
Choose the environment that fits the risk. The assurance logic and evidence contract stay the same; the status below tells you what exists today and what still needs a customer run.
View current deployment states
AWS
TARGET EVIDENCE RECORDED
A reference environment defined entirely in Terraform and applied: VPC with public and private subnets, EC2 with IMDSv2 required, RDS PostgreSQL, an asymmetric KMS signing key, Secrets Manager for the database credential, CloudWatch, and a least-privilege instance role with no access key anywhere.
Target-environment evidence is recorded; this is not production customer validation, certification or a Well-Architected review.
Microsoft Azure
NOT BUILT
Target: AKS with Entra ID, Key Vault and Azure Database for PostgreSQL, sharing the same evidence semantics.
No Azure packaging exists.
Google Cloud
NOT BUILT
Target: GKE or customer infrastructure with Cloud KMS and Cloud SQL, sharing the same evidence semantics.
No GCP packaging exists.
On-premises
RUNTIME BUILT - PILOT PENDING
EcoKure.App includes a container and local-first runtime for a customer's own workstation, server or private cluster.
No customer on-premises deployment or operating acceptance record exists yet.
Offline / air-gapped
RUNTIME BUILT - VALIDATION PENDING
The runtime defaults to no outbound call and verify-only checks work offline. Disconnected replay is the sovereignty path, not a fallback.
The end-to-end disconnected acceptance run has not been completed.
For a first paid pilot, start with the AWS reference path or the local/offline runtime. A marketplace listing is a route to procurement after onboarding, support and billing are ready; it is not a substitute for a customer acceptance record.
The AWS reference architecture
Written as Terraform and applied. This is the environment a Solutions Architect or a customer’s cloud team would review — every component with the reason it is there, because an architecture list without reasons is a parts bin.
View the AWS component detail
Layer
Component
Why it is there
Network
VPC, public and private subnets, route tables
The runtime and the database sit in private subnets. Nothing that holds evidence is publicly routable.
Compute
EC2 with IMDSv2 REQUIRED
IMDSv1 is the path an SSRF turns into stolen instance credentials. Requiring v2 closes it at the instance rather than in application code.
Database
RDS PostgreSQL, private subnet group, parameter group
The evidence chain is transactional. Interruption behaviour, backup and restore are proven against a real PostgreSQL, not against SQLite.
Signing
KMS asymmetric key (ECDSA P-256)
AWS KMS has no Ed25519 key spec, so the runtime carries both algorithms and dispatches on the one recorded with the key. Historical evidence stays byte-identical.
Secrets
Secrets Manager, AWS-managed database password
The credential is never written into Terraform state, which is itself a file somebody could read.
Identity
Least-privilege instance role, no access key
There is no long-lived credential on the instance to steal.
Observability
CloudWatch log group and agent
Structured verification logs and instance metrics, so a benchmark can be attributed to a machine state rather than asserted.
AWS target-representative proof
Measured run 2026-08-27 · ap-southeast-2 · TARGETREP_AWS_20260827
The same assurance path has now been exercised on the AWS reference environment: signed verification, PostgreSQL persistence, controlled recovery and clean teardown.
117,290verifications
0performance errors
19.47 msp95 latency
51.5 secrecovery
Read the figures with the hardware. Measured on t3.small compute and db.t4g.micro database, 20GB gp3 RDS, single-AZ. Both instance classes are burstable. Our own infrastructure audit records that a percentile measured while CPU credits drain describes a transient rather than the service, so these figures are a target-environment measurement and not a capacity claim. A sustained-load number needs a non-burstable re-run, which has not happened.
Full measurement record p50, sustained-soak throughput
14.29 msp50 latency
128.1soak verifications/sec
KMS: ECC_NIST_P256 with independent public-key verification · Store: RDS PostgreSQL · Loss: 0
Open machine-readable result →Boundary: Target-environment evidence, not production customer validation, certification, or a Well-Architected review. Cost signal: US$0.00001515 per modeled assurance transaction, not a production quote.
View staging foundation and capacity detail
Applied staging foundation
Captured 2026-08-29 · ap-southeast-2 · FOUNDATION_AWS_STAGING_20260829
The customer-controlled reference boundary is now provisioned. A one-task synthetic runtime smoke is recorded below; this does not claim a customer workflow, production readiness or an AWS endorsement.
Recorded staging smoke: one supervised customer-owned run exercised task identity, KMS signing, scoped storage, encrypted backup/restore, internal security headers and one synthetic request. The two remaining review gates are independent cross-tenant principals and external HTTPS ingress. Open the smoke EvidencePack →
Verifiedindependent sign & verify
52.882 mssigning latency p95
0errors across the curve
Configured, not measured
- PostgreSQL 16.15 evidence store
- Private database endpoint, no public route
- KMS storage encryption at rest
- Versioning enabled on the EvidencePack bucket
Full measurement record concurrency, throughput, tail latency and the stress boundary
265.942concurrent KMS tx/sec
2019.926 msconcurrent KMS p99
2000/2000KMS curve complete
178.36132-worker KMS tx/sec
1500/1500stability complete
161.506repeated KMS tx/sec
29.03432-worker stress tx/sec
KMS capacity curve: 2000/2000 completed with 0 errors. Tail latency rises at higher concurrency and is published rather than hidden.
| Workers | Transactions | Errors | p50 ms | p95 ms | p99 ms | Tx/sec |
|---|---|---|---|---|---|---|
| 1 | 500/500 | 0 | 47.693 | 51.292 | 305.713 | 18.469 |
| 8 | 500/500 | 0 | 48.526 | 54.969 | 835.671 | 115.326 |
| 16 | 500/500 | 0 | 51.59 | 93.492 | 1161.915 | 178.195 |
| 32 | 500/500 | 0 | 60.153 | 1762.408 | 1960.78 | 178.361 |
Repeated stability check: 3 rounds × 500 transactions completed with 0 errors at 16 workers. Worst observed p95 was 62.94 ms and worst p99 was 1399.471 ms.
Open stability EvidencePack →High-concurrency stress boundary: 3 rounds × 500 completed with 0 errors at 32 workers. Throughput fell to 29.034 tx/sec while worst p95 reached 1920.361 ms. This is a sizing signal: production should cap/queue concurrency and validate the limit in the customer runtime.
Open stress-boundary EvidencePack →US$0.00001515 per modeled assurance transactionUS$15.15 per million · reference model only, excluding runtime, database, network and operations.
Planning model
Translate the measurement into your workload.
Adjust the assurance volume to see the published KMS reference signal at your scale. This is not a quote or a full infrastructure estimate.
$1.52modelled KMS signal for 100,000 transactionsAt US$0.00001515 per transaction
Live application boundary: 600 of 600 read-only requests completed with 0 errors at 32 workers on the deployed Railway service, reaching 40.225 requests/sec. This is diagnostic capacity evidence; it is not a customer SLO or AWS production result.
Open runtime-boundary EvidencePack →Boundary: Infrastructure foundation evidence only. No customer data, production approval, APRA certification, AWS endorsement or application-runtime benchmark is claimed by this record.
Open staging foundation EvidencePack → Open live KMS benchmark → Open concurrent benchmark → Open capacity curve →Deployment gate ledger
Read-only checks from the authorized staging account
This ledger separates infrastructure that exists from the application deployment steps. The supervised six-check smoke is recorded below; the remaining review items are shown explicitly rather than folded into a green deployment badge.
View all gate checks
Runtime IAM policy shape PASS
4 statements inspected: service trust, tenant EvidencePack prefix, exact KMS and secret ARNs, no wildcard resources and no actuation actions. Open policy EvidencePack →
Runtime dependency lock PASS
43 packages are pinned and the Dockerfile installs the exact lock. Lock SHA-256: 74352a806768af7a… Open manifest EvidencePack →
Runtime SBOM inventory PASS
CycloneDX inventory of 43 locked components, tied to the same lock SHA-256. This is an inventory, not a vulnerability or license approval. Open SBOM EvidencePack →
Lock-bound vulnerability audit PASS NO KNOWN VULNERABILITIES
42 locked dependencies scanned with 0 known findings at scan time using pip-audit 2.10.1. Open audit EvidencePack →
Release integrity manifest PASS RELEASE INPUTS HASHED
Git source commit and 53 release inputs are SHA-256 bound, including the lock, SBOM and audit result. The customer staging image is pinned separately by digest in the image EvidencePack. Open integrity EvidencePack →
Runtime license inventory PASS LICENSE INVENTORY COMPLETE
43 of 43 locked packages have identified licenses. Legal and procurement approval remains pending legal and procurement approval. Open license EvidencePack →
Read-only deployed-runtime acceptance REVIEW REQUIRED
4 executed checks passed, 0 failed and 8 customer/environment gates remain pending. This probe does not mutate tenants, controls or customer data. Open acceptance EvidencePack →
Runtime deployment authority PASS
ECS authority: available · ECR authority: available · pinned image: supplied. Open preflight EvidencePack → Download reviewed authority policy →
Customer-owned ECR image SCAN COMPLETE
Digest-pinned image in ecokure-staging with 27 scan findings (6 critical, 12 high). This is staging evidence; it is not production approval. Open image EvidencePack →
Customer-owned AWS six-check smoke PARTIAL
Synthetic-only supervised run in ap-southeast-2: runtime identity, KMS signing, scoped storage, encrypted backup/restore, security headers and one controlled decision were exercised. Tenant isolation across independent principals and external HTTPS ingress remain review gates. Open smoke EvidencePack →
GitHub OIDC → ECR image path OPT-IN REVIEW
The reviewed Terraform module creates an immutable, scan-on-push staging repository and permits only repo:kyal102/ecokure:environment:staging to publish. It is disabled by default and still requires an account-owned OIDC provider and approved apply. Open the reviewed module →
Evidence storage runtime smoke PENDING RUNTIME ROLE SMOKE
The operator identity was correctly denied a write. The application runtime role must perform the synthetic put/get/read-back test before this boundary is called validated. Open storage smoke EvidencePack →
What remains before production deployment
The AWS run closes the measurement gap. These are the next gates for a customer-controlled production reference, kept visible so a benchmark is not mistaken for operational readiness.
Resilience and recovery
Move from single-AZ reference evidence to customer-approved multi-AZ design, backup/restore objectives and repeated recovery drills.
Operational ownership
Define staging, on-call ownership, alert thresholds, incident response, change approval and release rollback.
Security assurance
Complete threat modelling, dependency/SBOM review, penetration testing and customer IAM/network review.
Customer validation
Run one bounded pilot in the customer boundary, with their controls, data boundary, reviewers and written go/no-go criteria.
The same runtime on Azure and Google Cloud
Only the infrastructure boundary changes. The assurance semantics — the verdict contract, the signed chain, replay — are identical everywhere, or portability is not real.
View the portability map
| Portable layer | AWS | Microsoft Azure | Google Cloud | Customer / offline |
|---|---|---|---|---|
| Runtime artifact | OCI container on EC2, ECS or EKS | AKS or Container Apps | GKE or customer infrastructure | Docker or Kubernetes, disconnected |
| Transactional store | RDS PostgreSQL | Azure Database for PostgreSQL | Cloud SQL for PostgreSQL | Customer PostgreSQL |
| Signing key | KMS asymmetric, or CloudHSM | Key Vault or Managed HSM | Cloud KMS or Cloud HSM | PKCS#11 / local HSM |
| Evidence objects | S3 | Blob Storage | Cloud Storage | Customer object store |
| Identity | IAM + enterprise OIDC | Entra ID | Cloud Identity / OIDC | Customer directory |
| Observability | CloudWatch + OpenTelemetry | Azure Monitor + OpenTelemetry | Cloud Monitoring + OpenTelemetry | Customer SIEM |
| Evidence semantics | Identical. Same signed decision record, same chain construction, same replay. This row is the product. | |||
Azure and Google Cloud are mapped, not built. A target becomes supported only after the same signed decision can be replayed there.
What a Solutions Architect asks first
Answered here rather than in a meeting, including the answers that are “not yet”.
Open the architect answers
What is the workload shape?
Short, CPU-bound deterministic checks plus a signing operation and an append to a transactional store. No GPU. No model inference. The runtime carries 11 dependencies.
Where does customer data live?
Inside the customer’s account. The evidence store holds an input digest, not the input, so customer content does not enter it at all.
How is tenancy separated?
Tenant identity is resolved from the authenticated credential and never from a request field. Evidence attribution lives in a private index rather than on the published chain. Tested adversarially.
What is the failure mode?
Fail-closed by default: if the evidence store is unavailable, a strict deployment refuses rather than returning a verdict that looks attested and is not.
What does it cost per transaction?
Measured as a target-environment signal. The recorded modeled cost is US$0.00001515 per assurance transaction, excluding tax, support plans, free-tier credits, reserved pricing and shared-account costs. It is not a production price or customer quote.
Is it production-ready on AWS?
Not yet. The target-representative benchmark has passed, but this does not establish production customer validation, a Well-Architected review, a Foundational Technical Review or a marketplace listing.
What portability has to mean to count
Three properties. Two hold today and are checkable; the third is the one that needs a real deployment to prove.
Open the portability proof
- The evidence contract does not change. The same signed decision record, the same hash chain, the same replay semantics on every target.
- Verification needs nothing from us. An evidence pack is checkable with a standalone verifier that contains no EcoKure code, runs offline, and keeps working if EcoKure does not. That is what makes an exit plan real rather than contractual.
- An identical decision replays across targets. Proven for software upgrades. Not proven across clouds, because only one target has a written reference architecture and none has been applied.