Security
Security for BYOC
Nuon runs your app in your customers' cloud accounts with outbound-only connectivity, least-privilege roles, and access your customers control.
No direct access to your customers' cloud account.
Outbound-only runners, deny-by-default egress.
Customers do not share credentials or grant the vendor direct access to their cloud account. Everything goes through a runner the customer controls. The control plane holds no credentials and has no network path into the account. The runner polls outbound only, with deny-by-default egress limited to an allowlist. What it manages was created by the customer from a Stack they reviewed and deployed with their own credentials.
Runner API 
Artifact storage (S3) Vendor control plane API Runner API Artifact storage (S3) Vendor control plane API AWS (STS, ECR, S3, regional APIs) Amazon Linux repos CloudFront AWS (STS, ECR, S3, regional APIs) Amazon Linux repos CloudFront 
Docker Hub 
GHCR 
Quay 
Google Artifact Registry 
registry.k8s.io Docker Hub GHCR Quay Google Artifact Registry registry.k8s.io 
Jetstack · Kyverno · Prometheus · AWS 
HashiCorp GitHub 
Let's Encrypt Jetstack · Kyverno · Prometheus · AWS HashiCorp GitHub Let's Encrypt 
Datadog 
Wiz 
Okta 
Slack 
Snowflake Datadog Wiz Okta Slack Snowflake The BYOC software that powers your customers is open source.
Built to earn trust in production.
When Nuon powers a vendor's customer-facing production, the vendor's brand is on the line with their customers. Both need proof the platform is secure, reliable, and scalable, not only a claim. Nuon is open source, so vendors and end customers can inspect how it works, including the runner code that runs in the customer cloud, with issues and fixes public.
- Verify "Trust us"
- Permissions A PDF from the vendor
- Fixes Release notes
- Verify Read the code
- Permissions Defined in the Stack you review
- Fixes Public commits and issues
The Nuon control plane runs in your cloud.
Managed by Nuon, hosted in your account.
With Nuon BYOC, the control plane runs in your cloud account. Metadata and logs stay there, and runner access can be limited to maintenance windows. Prefer fully managed? Nuon Cloud runs the same platform, with encrypted metadata over TLS. On Nuon Cloud, vendors are segmented by organization, with RBAC limited to their own org.
- Runs in Nuon's cloud
- Managed by Nuon
- Metadata Encrypted Postgres
- Runner access Outbound only
- Runs in Your cloud account
- Managed by Nuon
- Metadata Stays in your cloud
- Runner access Restrictable to maintenance windows
Nuon Cloud · vendors segmented by organization
→ RBAC limited to their orgEach update or operation gets only the access it needs.
Separate roles for provision, maintenance, and deprovision.
Runners assume distinct IAM roles per operation. Components and actions declare their own roles and policies, so a runner never holds more access than the single job in front of it.
- PROVISION create stack apply terraform bootstrap BLOCKED run during maintenance PASS
- MAINTENANCE upgrade components run actions BLOCKED create sandbox PASS
- BREAK GLASS elevated debug time-limited BLOCKED permanent grant PASS
- DEPROVISION destroy resources revoke roles BLOCKED create components PASS
Vendor access is granted and audited by the customer.
Turn roles on or off, or elevate access to troubleshoot.
Everything the runner can do is granted by the customer through the Stack. They choose which roles are active, and can grant a time-limited break glass role for troubleshooting, then revoke it. No action from the vendor or Nuon is needed to take access away. The customer can even disable the runner entirely.
- runner DISABLED
- provision OFF
- maintenance ON
- deprovision OFF
- break-glass OFF
Customer sets the boundary
Illustrative · per-role toggles pending engineering review
Time-limited · revocable
Runner enabled only by the customer
Secrets stay in the customer's cloud, out of reach of the vendor and Nuon.
Customers enter secrets when they deploy the Stack.
Those values are written into the customer's AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. They are never stored in Nuon or held by the vendor. The runner in the customer's account can read them with a job-scoped role while it deploys or syncs components.
- Vendor BLOCKED no direct access
- Nuon control plane BLOCKED no credentials, no network path
- Runner PASS scoped role · deploy job only
Stays in customer cloud
We log infrastructure operations, not application logs.
Every Terraform run and Helm deploy, searchable per install.
Nuon logs infrastructure operations: Terraform, Helm, and cluster work, searchable per install. Application logs never reach the control plane. Nothing else is sent home automatically. Define an action to fetch only the data you want, and the runner returns that. The customer can audit and control what leaves.
Logged
- terraform runs
- helm deploys
- cluster creation
Never sent to control plane
- application logs
- app data
- secret values
Infrastructure operations only
Infrastructure policies are enforced automatically.
OPA and Kyverno gates on every change, plus drift detection.
Validate plans, charts, manifests, images, and sandbox infra with OPA and Kyverno, blocking or warning on violations. Checks run automatically before a change ever reaches an approval, and scheduled scans catch drift.
deploy · acme-prod · v2.1.0
instance-type
m5.4xlarge exceeds boundary
public-ingress
0.0.0.0/0 on load balancer
region-lock
eu-* only · ok
Enforce once · apply everywhere
scan · acme-prod
DRIFT DETECTEDaws_instance.worker.instance_type
aws_security_group.api.ingress
Scheduled scans catch drift
Nothing ships without an approval.
Approve the plan, prove it on a canary install, then approve each rollout.
Every change hits an approval gate. Plans must be approved before apply. Rollouts need approval for a canary, then again before each install group. Scope App Branches to one customer (stage, UAT, then production) or to a fleet (canary first, then the rest).
Nothing applies until approved
- stage → PASS plan approved · deployed
- uat → PASS plan approved · deployed
- production → Awaiting approval Approve
Production deploys only after stage and UAT
- canary → PASS smoke test passed · approved
- install group 1 → Awaiting approval Approve
- install group 2 → Queued
- install group 3 → Queued
Fleet rolls out only after canary approval
Found a security issue? Report a vulnerability.
Offer BYOC for any deployment architecture
Start your Nuon trial and try our example apps in minutes. No credit card required.