Composer (stacks)

A stack is a document that describes the resources of one setup in one location: networks, a NAT gateway, servers, volumes, firewalls, load balancers and IP addresses. Odinex compares the document with what the stack already runs, shows you a plan with what will be created, changed or deleted and what it costs per month, and applies it in the right order. The resources are ordinary resources: they appear in the console, the API and the CLI like any other.

The documentCopy Anchor Link

Each resource has a key, unique in the document, and a type. Resources refer to each other by key:

{
  "resources": [
    { "key": "net", "type": "network", "ip_range": "10.0.0.0/16" },
    { "key": "egress", "type": "nat_gateway", "network": "net" },
    { "key": "web-fw", "type": "firewall",
      "rules": [{ "direction": "in", "protocol": "tcp", "port": "80", "source_ips": ["0.0.0.0/0", "::/0"] }] },
    { "key": "web", "type": "server", "server_type": "t1", "image": "ubuntu-24.04", "count": 3,
      "public_ipv4": false, "public_ipv6": false, "networks": ["net"], "firewalls": ["web-fw"] },
    { "key": "lb", "type": "load_balancer", "load_balancer_type": "lb11", "network": "net", "targets": ["web"],
      "services": [{ "protocol": "http", "listen_port": 80, "destination_port": 80,
                     "health_check": { "protocol": "http", "port": 80 } }] }
  ]
}

Every resource can also have a name (defaults to the key) and labels. A server with count greater than 1 becomes that many servers. A stack holds at most 100 resources. Unknown fields are rejected, so a typo doesn't silently drop a setting.

Plan, then applyCopy Anchor Link

odx stack create --name shop --location fra1 --file stack.json   # YAML works too; - reads stdin
odx stack plan shop          # what would change and what it costs; exits 1 if there are errors
odx stack apply shop --wait  # do it

With the API: POST /v1/stacks (name, location, spec), then POST /v1/stacks/{id}/plan and POST /v1/stacks/{id}/apply.

The plan lists every resource with its action (create, update, delete or keep), the changes, and its monthly price, plus the stack's monthly cost before and after. Errors block the apply: unknown references, types or images, name clashes, or changes that can't be made in place.

Applying creates resources in dependency order (networks before servers, servers before load balancers) through the normal API, so the usual checks still hold: your balance, your limits and the location's availability. The stack's status shows applying, then applied, or failed with the reasons.

Changing a stackCopy Anchor Link

Save a new document (odx stack update shop --file stack.json, or PUT /v1/stacks/{id}), plan it, and apply. These changes are made in place:

• firewall rules and targets;
• load balancer services, targets and network;
• growing a volume;
• moving an Elastic IP or floating IP to another server;
• changing a server's count (servers are added or removed).

Other changes, such as a server's type or image, can't be made in place; the plan reports them as errors. Change those on the server itself, or remove the resource from the document and add a new one.

Deleting a stackCopy Anchor Link

odx stack delete shop (DELETE /v1/stacks/{id}) deletes the stack and all its resources. Add --keep-resources (?keep_resources=true) to delete only the stack and keep the resources as ordinary resources.

Your current setup as a graphCopy Anchor Link

odx stack topology --location fra1 (GET /v1/stacks/topology?location=fra1) returns the resources you already have in a location, with the links between them (networks, attachments, load balancer targets). A visual stack editor in the console builds on it.