Infra designer

The Infra designer lets you design AWS infrastructure for a project without writing Terraform first. You add resources from a catalog, connect them to each other, and OpsNexus checks the design, draws the architecture and generates Terraform. You can download the Terraform, or deploy it from OpsNexus with a plan, an approval and an apply.

The designer supports AWS only.

#Key ideas

• A stack is one piece of AWS infrastructure in one region, for example payments-prod. Stacks belong to the current project.
• A stack has a spec: a JSON document with the stack's resources and how they reference each other. Terraform is generated from the spec.
• Each save bumps the stack's version (v1, v2 …). Deployments use the version that was saved when the run started.
• Deployments run as an OpsNexus pipeline on your build agents. Terraform state is stored by OpsNexus.

#Permissions

All designer actions use the Cloud module in Access control:

#Create a stack

1. Open Infra designer in the sidebar and click New stack.
2. Enter a Name (unique in the project) and an optional Description.
3. Choose the Region and the Environment. The environment is free text in lower case, for example dev, staging, prod, qa or dr.
4. Optional: choose an AWS account. With an account, the designer lists the real availability zones, instance types and engine versions of the region. Without one, it uses built-in choices. The account is only read, never changed.
5. Under Start from, choose a template.
6. Click Create stack.

#Templates

With the prod environment, templates also turn on production options such as VPC flow logs, database log exports and monitoring, and load balancer deletion protection and access logs.

#The stack page

The stack page has five tabs: Design, Architecture, Terraform, JSON and Deploy. The header shows the region, environment, version, resource count, problem count and the AWS account. It has the buttons Download Terraform (.zip), Download JSON, Settings and Save.

Settings changes the stack's name, description, region, environment and AWS account.

#Design

The Design tab is a form-based editor:

• The Resources list groups the stack's resources by category. Click Add resource to pick a type from the catalog.
• Each resource has a Resource id (the Terraform resource name: lowercase letters, digits and _, starting with a letter) and a Name (the Name tag in AWS). Renaming the id updates references to it.
• The fields come from the catalog. Fields that point at another resource only offer resources of a compatible type, for example a subnet tier of a VPC in the stack, or security groups.
• Some fields follow others. For example, the instance type follows the CPU architecture (t3.micro for x86_64, t4g.micro for arm64), and the root volume grows to 30 GiB for Windows.
• Security group rules can be added from common presets such as HTTP, HTTPS, PostgreSQL, MySQL / Aurora, SQL Server, Redis / Valkey and NFS (EFS), with a CIDR or another security group as the source.
• Stack tags are added to every resource, together with ManagedBy, OpsNexusProject and OpsNexusStack, through the provider's default tags.

Edits are local until you click Save. While there are unsaved changes, a bar at the bottom offers Save, Check for problems and Discard changes, and OpsNexus warns you before you leave the page. Downloads, the diagram and the Terraform tab show the last saved version.

#Architecture

The Architecture tab draws the saved design: AWS Cloud, then the region, the VPC, availability zones and subnet tiers, with resources inside their subnets. Regional services sit in the region, and CloudFront and Route 53 in a Global group. Arrows show network, data, security and control links. Click Download SVG to save the diagram.

#Terraform and JSON

The Terraform tab lists the generated files with a code viewer and a Copy button. The JSON tab shows the spec (opsnexus.json), including unsaved changes.

#Supported AWS resources

Defaults are secure: encryption on, S3 public access blocked, IMDSv2 required, RDS private with deletion protection on, and the RDS master password managed by AWS Secrets Manager. A Secret (Secrets Manager) is created without a value; you set the value in AWS so it never appears in Terraform code or state.

#Key pairs

A Key pair can be generated by OpsNexus or imported from your public key.

• Generated: OpsNexus creates the pair, keeps the private key encrypted (never in Terraform) and lets you download the .pem. Save the stack, then download it. Downloads are audited.
• Imported: paste your public key (ssh-keygen -y -f mykey.pem prints it). OpsNexus never sees the private key.

#Validation

OpsNexus checks the design every time you save, and when you click Check for problems. It returns every finding at once, in two kinds:

• Problems are errors. They block deployments. Examples: an invalid or overlapping CIDR, a reference to a missing resource, an S3 bucket name that breaks AWS rules, an HTTPS listener without a certificate, a public IP in a private subnet, or an instance type of the wrong CPU architecture.
• Recommendations are warnings. They do not block anything. Examples: a database in public subnets, a policy that allows * on *, and in prod stacks, missing flow logs, backups, deletion protection or access logs.

A stack is saved even when it has problems. The header shows the number of problems and recommendations.

#Generated Terraform

The Terraform targets Terraform >= 1.6 and the hashicorp/aws provider ~> 6.0. It follows the standard module structure:

<stack>/
├── modules/stack/          # the resources, one file per area
├── environments/<env>/     # the root module you run Terraform in
│   ├── main.tf             # module "stack"
│   ├── providers.tf
│   ├── variables.tf
│   ├── terraform.tfvars
│   └── outputs.tf
├── README.md
└── opsnexus.json           # the spec

To use it outside OpsNexus:

unzip payments-terraform.zip -d payments
cd payments/environments/prod
terraform init
terraform plan

#Deploy from OpsNexus

The Deploy tab plans and applies the stack with Terraform.

#Before the first run

You need:

• An AWS access key credential with permission to create the stack's resources. Create it in Secrets and variables. The credential must allow pipelines to use it. This is separate from the read-only cloud accounts.
• A build agent that can run Docker. Terraform runs in the hashicorp/terraform:1.16 image. The first run on an agent downloads the AWS provider, so it takes longer.

Then, in Deploy settings:

1. Choose the Deploy credential.
2. Set Agent labels (comma-separated, default docker). The run goes to an agent that has all of these labels.
3. Click Save deploy settings.

#Check permissions

The AWS permissions card checks whether the deploy credential can create what the stack needs. Click Check permissions. OpsNexus finds the credential's IAM identity and runs the IAM policy simulator for the actions the design needs. If any are missing, it shows them and a ready-made IAM policy to attach to the user or role.

The same check runs before every Plan and Deploy. Missing actions block the run. If the credential cannot run the simulator itself, someone with full access can click Deploy without the permission check. Destroy runs skip the check.

#Plan, approve, apply

A run can start only when the design has no problems, is saved, the deploy settings are saved, and no other run of the stack is active.

To deploy:

1. Click Deploy (plan → approve → apply). A new run appears in Runs.
2. Wait for the plan. The Plan section lists each change: Create, Update in place, Replace (destroy, then create) or Destroy. A warning appears when the plan deletes or replaces resources.
3. Someone with full Cloud access reviews the plan, adds an optional comment, and clicks Approve (or Approve (includes deletions)) or Reject. Approval can also be given from the build page.
4. After apply, the Outputs section lists the Terraform outputs. Sensitive outputs are not stored.

Run statuses are Queued, Planning, Planned (plan-only runs), Awaiting approval, Applying, Succeeded, Failed, Rejected and Cancelled. Click Open build log to see the pipeline run, or Cancel to stop a run.

Each stack gets a generated pipeline named infra-<stack> in Pipelines. OpsNexus regenerates it for each run; do not edit it.

RDS databases have deletion protection on by default, and so do internet-facing load balancers in prod templates. Destroy fails until you turn it off on the Design tab and deploy that change first.

#Terraform state

OpsNexus stores each stack's Terraform state itself, as a Terraform HTTP backend with locking. The state is encrypted, and the last 20 versions are kept. You do not need an S3 bucket or DynamoDB table.

The Current state card shows the resources in state, the serial, when it was updated, the lock, and the last applied run. Users with full access can:

• Click Download state to get the current state file.
• Click Force unlock to release a lock left by a crashed run. Only do this when no run is using the state.

#Connect to instances

After a successful apply, the Connect to instances card lists each EC2 instance with an Open in AWS console link and commands for Session Manager, SSH (with the key pair and the OS login user), EC2 Instance Connect and, for Windows, RDP. For Windows instances with an OpsNexus-generated key, Get Administrator password decrypts the password. This action is audited.

#Delete a stack

On the Infra designer list, click Delete and type the stack name. This removes the design, its generated pipeline and its generated private keys from OpsNexus. Nothing in AWS is changed. To remove the AWS resources, run Destroy first.