Application Delivery Controller

AS3 Declarative Deployments

Generate, edit, and deploy F5 AS3 (Application Services 3) declarations for a virtual server straight to a BIG-IP's REST endpoint — no Ansible — with a form or code editor, git-backed source of truth, dry-run validation, and collector-routed delivery for on-prem devices.

AS3 — F5's Application Services 3 Extension — lets you describe an application service (a virtual server, its pool, members, monitors, and TLS) as a single JSON declaration and POST it to the BIG-IP, which reconciles the box to match. Versus turns each virtual server in your inventory into an AS3 declaration you can review, edit, version in git, and push to the device — declaratively, without generating or running Ansible.

This is the lightest-weight of the three F5 deploy paths in Versus. There is no playbook and no site build: the declaration goes straight to the BIG-IP's AS3 REST endpoint (/mgmt/shared/appsvcs/declare). The same delivery is collector-aware, so an on-prem F5 on a private LAN is reached the same way a cloud-reachable one is.


How it works

An AS3 deployment has three moving parts: generation (turning a VS into a declaration), the declaration itself (versioned in git), and delivery (the AS3 REST call to the device).

Generation from a virtual server

Versus builds the declaration from the VS and its pool records already in inventory. The generator maps database fields onto AS3 constructs:

  • The VS partition becomes the AS3 Tenant; the VS name becomes the Application.
  • A service class is inferred from the VS: UDP protocol → Service_UDP; port 443 or an ssl/https name → Service_HTTPS; port 80 → Service_HTTP; otherwise Service_Generic.
  • The pool's load-balancing mode is carried across (round-robin, least-connections-member, ratio-member, fastest-app-response, and the other standard BIG-IP methods), and pool members are grouped by service port.
  • Health monitors become bigip references (e.g. /Common/http); an HTTPS service gets a default serverTLS of /Common/clientssl.
  • The declaration carries a stable identity — a UUID derived from device/vs-name — so re-deploying the same VS updates the same AS3 application rather than creating a duplicate.

The result is a standard AS3 document pinned to schema version 3.56.0:

{
  "class": "AS3",
  "action": "deploy",
  "persist": true,
  "declaration": {
    "class": "ADC",
    "schemaVersion": "3.56.0",
    "id": "urn:uuid:…",
    "label": "web_vs",
    "remark": "Generated by Versus v2 — bigip-01 — 2026-08-19T12:00:00Z",
    "Common": {
      "class": "Tenant",
      "web_vs": {
        "class": "Application",
        "template": "generic",
        "serviceMain": {
          "class": "Service_HTTPS",
          "virtualAddresses": ["10.0.0.10"],
          "virtualPort": 443,
          "pool": "web_pool",
          "serverTLS": { "bigip": "/Common/clientssl" }
        },
        "web_pool": {
          "class": "Pool",
          "monitors": [{ "bigip": "/Common/http" }],
          "loadBalancingMode": "round-robin",
          "members": [
            { "servicePort": 8080, "serverAddresses": ["10.0.1.11", "10.0.1.12"], "enable": true }
          ]
        }
      }
    }
  }
}

Delivery — the AS3 REST call

Deployment POSTs the declaration to /mgmt/shared/appsvcs/declare on the target BIG-IP. Versus reads the per-tenant results array the AS3 extension returns and reports each tenant's outcome; a deploy succeeds only when every tenant result carries a 2xx code. Because AS3 is declarative, the extension itself works out the create/modify/delete operations needed to make the device match the declaration.

Delivery is collector-aware. For a collector-managed (site-bound, private-LAN) F5, the call is routed through the collector tunnel rather than reaching across the internet; where a collector-side credential mapping exists, the collector terminates TLS and injects the device credential locally, so no device password leaves your network. A cloud-reachable device is called directly over REST. Either way the operator experience is identical.


Using it from a virtual server

Open a virtual server and switch to the AS3 / JSON or AS3 / YAML tab. The tab loads the current declaration: if the VS has already been saved to a repo file, you see the committed content (source: git); otherwise you see freshly generated content (source: generated) with a note that it hasn't been saved yet.

You work with it two ways:

  • Editor view — a Monaco code editor with JSON or YAML syntax, for hand-editing the raw declaration.
  • Form view — structured fields for tenant, application, service class, virtual address and port, load-balancing method, monitor, and pool members. Apply renders the form back into a declaration in the editor.

Save, push, deploy

Three actions run left to right across the tab, and they are gated in order — you cannot deploy a declaration that isn't committed to git:

ActionWhat it does
Save to RepoWrites the declaration to a git-backed file for this VS ({group}/{vs_name}.as3.json or .as3.yaml). If the repo can't be inferred, Versus prompts you to pick one.
Git PushPushes the committed file to the repo's remote. Disabled while there are unsaved edits.
Run WorkflowRuns the AS3 deploy workflow against the committed file. Disabled until the file is saved to a repo.

Run Workflow offers two modes:

  • Dry run — validates the declaration on the device without changing anything (AS3's own dry-run evaluation). No writes, no git push.
  • Apply changes — deploys to the device for real and pushes the committed file back to git. This one asks for confirmation first.

Both modes open the resulting workflow run so you can watch it execute step by step.


Under the hood — the deploy workflow

The Run Workflow button doesn't call the device directly. It launches a seeded workflow (f5-as3-from-file) that takes the change through the git flow so the applied configuration is recorded, not just pushed:

  1. Pull the repo (via the collector for a site-bound repo).
  2. Read the committed AS3 file.
  3. Deploy the declaration to the device's AS3 endpoint.
  4. On a real (non-dry-run) apply, push the file back to git so the on-prem repo records what was applied.

At the center is a single workflow step, f5.as3_deploy — an F5 AS3 Deploy action you can also drop into any workflow you build yourself. It resolves the declaration from one of three sources, in priority order:

SourceHow it's supplied
InlineA raw AS3 declaration passed directly in the step config (declaration). Overrides the others.
Repo fileA committed .as3.json / .as3.yaml pulled and read from git (repo_id + file path). YAML is converted to JSON for the REST call.
GeneratedBuilt on the fly from a VS id (generate_vs_id).

The step's other inputs are the target device (an explicit device_id, or the first F5 in the run's device group) and check_mode. With check_mode on, Versus sets the declaration's action to dry-run before sending it, so AS3 evaluates the change without applying it — the same "dry run" the UI exposes.

Because it's an ordinary workflow step, AS3 deploys can be composed with pre-checks, approvals, and back-outs, scheduled, or triggered from the API like any other automation.


When to use AS3 vs. the other F5 paths

Versus offers three ways to push F5 configuration, and each virtual server exposes tabs for all of them. AS3 is the right choice when you want a declarative, idempotent application definition delivered with the least machinery:

  • AS3 deploy — declare the whole service as JSON and let the BIG-IP reconcile. No Ansible, no controller, fastest path for the app-service shape AS3 covers.
  • Ansible modules — imperative, field-by-field changes via F5 Ansible collections, for drift remediation and edits AS3 doesn't model.
  • Site build — full templated site provisioning.

All three share the same git-backed, collector-routed foundation, so you can standardize on AS3 for application delivery and fall back to the others where you need them. See the F5 BIG-IP Integration guide for the wider picture.


Notes and constraints

  • Schema pinning. Generated declarations target AS3 schema 3.56.0; the BIG-IP must have a compatible AS3 extension installed for a deploy to succeed.
  • Git is the source of truth. You must Save to Repo before you can deploy — the workflow always deploys the committed file, never unsaved editor content, so what runs is what's in version control.
  • Per-tenant results. A deploy reports each AS3 tenant's outcome individually; a mixed result (one tenant fails) is surfaced as a failure with the offending tenant's message.
  • Credentials stay put. Device credentials come from the Versus Vault or, for collector-injected devices, never leave the local network at all.

Related