Infrastructure automation
Infrastructure as a step in the business process, not a separate world.
Kubernetes operations, infrastructure as code, cloud actions and deployments run as governed workflow steps, triggered by the business events and approvals that actually create the need.
One run, both domains
The business event that justified a change and the infrastructure operation that performed it belong to the same execution record.
- and OpenShift-class distributions
- Kubernetesand OpenShift-class distributions
- plan and apply in workflow
- IaCplan and apply in workflow
- credentials and RBAC
- Vault-backedcredentials and RBAC
- capable execution
- Air-gappedcapable execution
Operation
Infrastructure work rarely starts in infrastructure.
Environments get created because a project was approved, a customer was onboarded or a contract was signed. Automating only the cluster half of that leaves the request, the approval and the evidence somewhere else.
Requests start in the business
A new customer, a new project, an onboarding or a contract signature is usually what creates the need for an environment, a namespace or a capacity change.
Approvals sit between the two
Someone has to authorize spend, access or a production change. Keeping that approval in the same run as the change removes the gap between decision and execution.
Evidence has to cover both halves
An audit question about a production change usually starts with why it happened. That answer lives in the business event, not in the cluster.
Specialist tools remain in place
Nexus calls your existing infrastructure tooling as part of a wider process rather than asking platform teams to abandon what already works.
Operations
What runs as a workflow step.
Each operation is a configured node with typed inputs, vault-backed credentials and recorded output, so an infrastructure change is governed the same way a system write-back is.
Kubernetes operations
Namespaces, workloads, scaling, restarts and resource inspection as configured steps.
kubectl-style actions
Familiar cluster operations expressed as workflow nodes with typed inputs and recorded output.
Terraform and IaC
Plan and apply runs invoked from a workflow, with the plan available for review before apply.
Cloud provider actions
Compute, storage, networking and identity operations against your cloud accounts.
Deployments
Release steps executed as part of a governed sequence rather than an ad hoc console action.
Templates
Parameterized definitions so the same environment shape is produced consistently.
Multi-cluster operation
Target the right cluster or region per run instead of maintaining a workflow per environment.
Server and appliance access
SSH steps for systems that are not managed through an API.
Where an operation is not covered by a configured action, a code node reaches the relevant API or CLI in the runtime that fits the task, from Python, Bash, Go, Java, .NET, PHP, PowerShell and JavaScript/TypeScript through Deno.
Triggers
What starts an infrastructure workflow.
Sources span business systems, source control, platform signals and schedules, which is what allows one workflow to span the request and the change.
Business events and approvals
A signed contract, an onboarding record or an approved request begins the provisioning sequence.
Git events
Repository activity such as a merge or a tag can start a validation, deployment or synchronization workflow.
Infrastructure and platform events
Cluster, monitoring and platform signals start response workflows that gather context before anything is changed.
Schedules
Recurring hygiene work such as drift checks, certificate reviews and environment cleanup.
Service requests and forms
A structured request captures the parameters the workflow needs, so provisioning does not start from a chat message.
API invocation
Existing portals and internal tools call a Nexus workflow instead of holding cluster credentials themselves.
Environments
Where these workflows run.
Nexus is vendor-neutral about the platform underneath. What matters is that the execution layer sits inside the boundary you control.
On-premise
Your own data centers, including environments with no route to the public internet. Workflows, credentials and evidence stay on your infrastructure.
Private and sovereign cloud
Dedicated tenancies and sovereign regions where jurisdiction and operator control are part of the requirement rather than a preference.
Kubernetes distributions
Upstream Kubernetes and enterprise distributions including OpenShift-class platforms, across single and multi-cluster estates.
Worked example
A cross-domain provisioning run.
A business approval starts it, deterministic rules validate it, a platform owner authorizes it, and the infrastructure change plus its validation are recorded against the same request.
- 01
Trigger
A new project is approved in the business system and a provisioning request is created with its parameters.
- 02
Integration
Connector and database steps retrieve the cost center, data classification, region requirement and owning team.
- 03
Rules + Code
Deterministic checks validate naming, quota, entitlement and residency rules, and code assembles the parameter set for the infrastructure definition.
- 04
Sovereign AI
A self-hosted model summarizes the request and highlights differences from comparable environments for the reviewer to consider.
- 05
Human Approval
A platform owner reviews the plan output, cost implication and residency decision, then approves, adjusts or rejects.
- 06
System Action
The workflow applies the infrastructure definition, creates the namespace, deploys baseline components and runs validation checks.
- 07
Audit
Request, checks, plan, approval, applied changes and validation results are retained with the run.
- 08
Rollback path
If validation fails, the workflow reverses what it created and reports the failure with the diagnostic output attached.
Controls
Credentials, authority and evidence.
Infrastructure automation concentrates power. The controls around it are the part that determines whether it can be used in a regulated environment.
Vault-backed credentials
Cluster credentials, cloud keys and SSH material are stored in the vault and referenced by nodes. Teams can run a workflow that uses a credential without holding it themselves.
Role-based access
Who may run which workflow, and who may approve a sensitive step, follows roles and workspace boundaries rather than distribution of cluster access.
Approval before consequential change
Production applies, destructive operations and cost-bearing provisioning can require an explicit human decision inside the run.
Revisions and safe change
Infrastructure workflows are edited as draft revisions and tested before publication, so the definition of a change is itself version controlled.
Execution history
Each run records what was targeted, what was applied and what the systems returned, which is the record an auditor actually asks for.
Validation and reversal
Post-change checks confirm the result, and failure paths can reverse partial work rather than leaving an environment half-created.
Examples
Where teams apply it.
These are illustrative patterns across provisioning, operations, release and access work rather than claims about specific organizations or results.
Provisioning
Environment on business approval
An approved project creates a namespace, baseline services, access groups and monitoring, with parameters derived from the business record rather than typed twice.
Operations
Scale and remediate on a platform event
A capacity or health signal starts a workflow that gathers diagnostics, applies a defined remediation and escalates to a person when the situation is outside policy.
Release
Deployment with a governed gate
A Git event starts validation and staging deployment, and the production step waits for an approval that is recorded with the release.
Access
Time-bounded elevated access
An approved request grants access, records the justification and schedules the revocation as part of the same execution.
Hygiene
Drift and cleanup runs
Scheduled workflows compare intended and actual state, open a review for meaningful differences and remove environments whose owning record has closed.
Offboarding
Decommission on contract end
A closed project triggers backup, confirmation from the owner, teardown of the environment and a retained record of what was removed.
Operation
Operating responsibilities.
Platform teams already own good tooling. Nexus is the layer that connects it to the rest of the organization.
Specialist tools retain their roles
Your infrastructure as code tooling, cluster platform, CI system and observability stack keep their jobs. Nexus orchestrates them inside a wider governed process.
Your team defines the standards
Standards, module design and cluster architecture remain your team's work. Nexus executes and governs those decisions, it does not make them.
APIs, CLI and code extend actions
Coverage varies by provider and platform. Where a configured action does not exist, direct API access, CLI invocation and code nodes carry the operation.
Architecture session
Connect the approval to the change.
If provisioning starts with a form and ends with someone running commands by hand, the gap is where the audit questions live. Bring us that process and we will design it as one governed run.