Security best practices
This guide describes recommended security practices for teams using nullplatform. It covers how to manage access, protect sensitive configuration, run pipelines safely, and maintain visibility over your services.
These practices apply regardless of the infrastructure your organization uses. Nullplatform is infrastructure-agnostic: the recommendations here focus on how you configure and operate the platform itself.
Governance and access management
Use namespaces to separate teams, products, or domains
Namespaces are the primary way to organize applications within an account. Use one namespace per team, product, or business domain (for example, checkout, billing, or platform). This logical separation keeps misconfigurations contained and makes it easier to control access separately for each area.
Assign roles with minimum privilege
In nullplatform, a role defines what actions are allowed, but it only takes effect when combined with a grant that ties the role to a specific resource (NRN). Assign the most restrictive role that still allows the person to do their job, and scope the grant to the narrowest resource possible, such as a namespace or application rather than the whole organization.
Automate user lifecycle with SAML and SCIM
If your organization uses an identity provider (Google, Okta, or Azure Entra ID), configure SAML-based SSO so that authentication is centrally managed. For teams using Azure Entra ID, enable SCIM 2.0 provisioning to automate user creation, deactivation, and role assignments so that no manual steps are needed when people join or leave.
Revoke access immediately when someone leaves
When a team member is offboarded, remove their user and any grants assigned to them in nullplatform. If SCIM provisioning is active, deactivating the user in your identity provider automatically removes their access in nullplatform. Otherwise, revoke access manually and make sure this step is part of your offboarding checklist.
Treat API keys separately from personal tokens
CI/CD pipelines and automation scripts must use dedicated API keys (machine users), not personal access tokens. Create each API key with the minimum required roles and scope its grants accordingly. Rotate keys on a regular basis and revoke any that are no longer needed or belong to decommissioned systems. When a credential stored in a parameter is updated at the source, update its value in nullplatform and trigger a new deployment: parameters are not hot-reloaded. Never expose API keys in source code or logs.
Secrets and parameter management
Centralize all secrets and configuration in parameters
Use nullplatform parameters to store API keys, credentials, and sensitive environment variables. Avoid hardcoding sensitive values in source code, pipeline definitions, or Dockerfiles. Parameters are versioned: every change creates a new version, which provides a full audit trail and lets you roll back if needed.
Mark sensitive parameters as secret
When a parameter contains sensitive data (passwords, tokens, private keys), mark it as secret. Reading the value of a secret parameter requires specific permissions. For especially sensitive cases, you can require an approval request before the value is revealed, adding a human review layer on top of role-based access.
If the parameter holds a credential that comes from an infrastructure dependency (a database, a queue, a cache), consider linking it through a service instead of creating it manually. When a service links to an application, it creates the parameters automatically and marks them as read-only: only the service can update them. This means credential changes flow through a service action rather than a direct parameter edit, giving you traceability and making approval policies applicable to the change.
Protect critical configuration with read-only parameters
Read-only parameters are created by services, not set manually from the platform UI. When a service links to an application and exports credentials or configuration values, those parameters are automatically marked as read-only: only the service can update them. This protects values like production database endpoints or compliance-related flags from being changed directly, and ensures any modification goes through the service that owns them.
Scope parameter access by environment using dimensions
Use dimensions to apply parameters to groups of scopes sharing the same environment, region, or other attribute (for example, environment=production). This lets you manage production secrets separately from development ones without configuring each scope individually, and makes access control more predictable.
Pipelines and builds
Do not embed secrets in build artifacts
Ensure that build artifacts do not contain credentials, tokens, or sensitive values. Secrets must be injected at runtime through parameters, not baked into images at build time. Scan build outputs regularly to verify that no sensitive data is accidentally included.
Reference parameters from pipelines, never inline values
Use nullplatform's parameter injection in your pipeline definitions instead of defining sensitive values inline. This keeps secrets out of version control, keeps them in one place, and ensures that pipeline runs always use the current approved value.
Gate production deployments with approval policies
Use nullplatform approvals to enforce fine-grained control over what reaches production. Policies can block deployments automatically based on conditions: requiring a minimum test coverage threshold, that auto-scaling is enabled, or that a minimum number of instances is configured. When conditions are not met, the deployment can be held for manual review rather than rejected outright.
Require successful staging deployment before production
Configure approval policies so that a build must be successfully deployed to a staging environment before it can reach production. This enforces progressive promotion and prevents untested changes from going directly to production. See the step-by-step tutorial for a complete setup example.
Deployment strategies and availability
Nullplatform supports deployment strategies that control how traffic shifts to a new version and under what conditions a rollback is triggered automatically. Choosing the right strategy for each environment and integrating it with telemetry is one of the most effective ways to protect availability during deployments.
Use Blue-Green with metric-based rollback for production
Blue-Green gradually shifts traffic from the old version to the new one in configurable increments (for example, 10% every 30 seconds). If a defined metric threshold is breached during the rollout (for example, HTTP error rate exceeding 0.3), the platform automatically rolls back to the previous version. Use this as the default strategy for any production scope where two versions of the application can run simultaneously.
Reserve All-In for development or urgent hotfixes only
The All-In strategy cuts over all traffic instantly with no gradual rollout and no automatic rollback. It is best suited for low environments (development, QA) where speed matters more than safety, or for urgent hotfixes where the change has been thoroughly validated and a gradual rollout would delay resolution. Avoid using it as the default in production.
Configure step size and interval deliberately
Blue-Green allows you to configure both the traffic increment step (from 5% to 100%) and the interval between steps (1 to 120 seconds). Smaller steps and longer intervals give telemetry more time to surface issues before the full rollout completes. For critical services, prefer steps of 10% or less with intervals of at least 30 seconds.
Define rollback rules tied to real service metrics
Rollback rules are evaluated against metrics emitted by the telemetry provider during the rollout window. Define rules using meaningful thresholds for your service. For example, roll back if http.error_rate exceeds 0.3, response_time exceeds a baseline, or cpu_usage spikes beyond normal. At least one metric rule should be active on every production Blue-Green strategy.
Use policies to control which strategies are available per environment
You can restrict which deployment strategies are selectable per namespace, application, or dimension (for example, environment=production). Use this to prevent developers from accidentally selecting All-In for a production deployment. Define a curated set of approved strategies for production and enforce them through platform policies.
Deploy to multiple scopes together for consistency
Deployment groups let you deploy the same build to multiple scopes at once while maintaining individual control over each. Use groups when a release must reach several regions or environments simultaneously. Each deployment within the group can be individually rolled back if needed, while the group provides centralized visibility.
Strategy comparison
| Strategy | Traffic switch | Auto-rollback | Recommended for |
|---|---|---|---|
| Blue-Green | Gradual (configurable steps) | Yes, metric-based | Production deployments |
| All-In | Instant (100% at once) | No | Dev/QA or urgent hotfixes |
Blue-Green with small steps (10%) and a 30-second interval effectively behaves like a canary deployment, exposing a small fraction of traffic to the new version before proceeding. This is the recommended approach for high-traffic or sensitive production services.
Application and service organization
Use catalog specs to enrich builds and applications with security metadata
Define catalog specifications to attach structured, validated fields to your builds and applications. This metadata flows into dashboards like Insights and can be referenced directly in approval policies to gate production deployments based on real build data.
Keep services active only while they are in use
Review the services registered in the platform periodically and decommission any that are no longer actively used. Orphaned services may retain configurations and access that represent unnecessary surface. Use the Insights view to identify services with no recent activity.
Maintain clear environment separation across scopes
Keep development, staging, and production environments in distinct scopes with separate configurations and access controls. Use dimensions to group scopes consistently (for example, environment=production) so that policies and parameters apply predictably across the right set of environments.
Observability and anomaly detection
Telemetry in nullplatform surfaces logs and performance metrics from your running scopes and services directly in the platform UI. It works through the nullplatform agent and is the data source that powers metric-based rollback during deployments.
Configure a telemetry provider before enabling metric-based rollback
Metric-based rollback in deployment strategies reads directly from the telemetry provider. If telemetry is not configured and emitting data, rollback rules will have nothing to evaluate against and will not trigger. Nullplatform supports Datadog, Dynatrace, Prometheus, and AWS CloudWatch as telemetry providers. Ensure the provider is running and metrics are visible in Analyze > Performance before relying on automatic rollbacks.
Configure the telemetry provider at the right level
Telemetry providers can be configured at the organization, account, namespace, application, or scope level. A provider configured at a higher level is inherited by all resources below it. Override at a lower level only when a specific application or scope requires a different observability backend than the rest of the organization.
Monitor logs and metrics per scope
Agent-backed scopes support both logs and performance metrics. Review logs in Analyze > Logs and performance metrics in Analyze > Performance to maintain visibility into runtime behavior. Correlate log patterns with metric changes to identify the source of degradations during or after a deployment.
Instrument services and track their performance
Services support performance metrics through the telemetry provider (logs are not available for services, only for agent-backed scopes). Use service-level metrics to detect anomalous behavior in downstream dependencies, not just in the application scope itself. A service degradation during a deployment window may indicate a compatibility issue introduced by the new release.
Set up notifications for deployment and approval events
Configure notification channels to alert your team on critical pipeline events: approval requests pending review, production deployment failures, or scope stop/delete actions. Nullplatform supports routing these events to Slack, HTTP webhooks, GitHub, GitLab, Azure, or your own agent. Use filters with MongoDB query syntax to route only the events that matter to each channel.
Use Insights to monitor delivery health
Use the Insights view to track deployment frequency, lead time, and failure rates via DORA metrics. A sudden drop in deployment frequency or a spike in failure rate can signal a process or security issue worth investigating.