A transition guide for teams leaving tmsh, the Configuration Utility GUI, and per-object Ansible behind — enable AS3, connect a git repo as the source of truth, convert each virtual server into its own AS3 file, then modify pool members, persistence, and monitors through a governed form (embeddable in ServiceNow) whose workflow pulls git, pushes the change back, and deploys to the device.
Most F5 estates are managed three ways at once: tmsh on the CLI, the Configuration Utility GUI for point-and-click changes, and a drawer of per-object Ansible playbooks that each poke one field on one object. All three are imperative, and none of them records the finished state. Drift creeps in, the GUI and the playbooks disagree, and every change is a fresh act of remembering which knobs to turn.
AS3 — F5's Application Services 3 Extension — replaces all three with one idea: describe an application service as a single JSON declaration and let the BIG-IP reconcile itself to match. Versus takes that one step further: git is the source of truth. Each virtual server becomes its own AS3 file in a repo, and every change flows pull → apply → push to git → deploy to the device, so what's running is always what's committed.
This guide is the path from the old world to that one — enable AS3, connect git, convert what you already run, and modify a virtual server through a governed, ServiceNow-embeddable form.
For the per-virtual-server AS3 reference — the tabs, the f5.as3_deploy step — see AS3 Declarative Deployments. This page is the transition.
| You do this today | Versus AS3 replaces it with |
|---|---|
tmsh modify ltm virtual … object by object | One declaration per VS; the BIG-IP computes the create/modify/delete itself |
| Clicking through the Configuration Utility | A reviewable JSON file — diff it, comment on it, version it |
| A playbook per object, run in the right order | A single deploy to /mgmt/shared/appsvcs/declare; no ordering, no idempotency bookkeeping |
| "What's actually on the box?" answered by logging in | The committed file is the state; re-deploying an unchanged one reports no change |
| Config lives in the device and in tribal memory | Config lives in git, one file per VS, deployed through a workflow that records every change |
AS3 is not all-or-nothing. It runs alongside tmsh on the same box — you can convert one application and leave the rest exactly as it is.
AS3 ships as an iControl LX extension (an RPM) on the BIG-IP's management plane — a one-time enablement per device, no reboot. Check whether it's present:
curl -sku admin:<password> https://<bigip-mgmt>/mgmt/shared/appsvcs/info
On the lab BIG-IP this returns — proving the extension is installed and which schema it speaks:
{ "version": "3.56.0", "release": "10", "schemaCurrent": "3.56.0", "schemaMinimum": "3.0.0" }
The installed package shows up as f5-appsvcs-3.56.0-10.noarch. If it isn't there, download the matching RPM from the F5 AS3 releases, upload it, and install it through the package-management task API. Versus generates against schema 3.56.0, so match the extension to that or newer.
For a collector-managed, private-LAN BIG-IP you never expose the management address — Versus reaches these endpoints outbound-only through the collector.
Because git is where AS3 lives, connecting a repo is a prerequisite — the Convert step won't save without one. Under Integrations → Git Repos, add a repo: give it a URL and branch, and — for an on-prem estate — a collector site, so git runs on the collector and credentials are sealed into the collector's local vault (they never leave your network).
A repo bound to a site is reached the same outbound-only way the device is, so the same collector that deploys to the BIG-IP also pulls and pushes the AS3 files. One file per virtual server lands under {device-group}/{virtual-server}.as3.json.
You don't hand-write AS3 for an estate you already operate. On an F5 device, Convert to AS3 reads every virtual server, pool, member, monitor, and TLS profile and writes one AS3 file per VS into the repo — not one giant declaration. Pick the target repo (the wizard won't proceed without one), review the list of virtual servers and which already have a committed file, and commit them all in a single push. Each VS carries a stable identity, so re-converting updates its file in place rather than cloning.
Prefer to go one at a time? Every virtual server's detail page has an AS3 tab that shows the same declaration and tells you its source — git when a committed file exists for that VS, generated when it doesn't yet — so you can convert, review, and commit a single application and watch its file appear in the repo.
A note on the
Commonpartition. AS3 reserves theCommontenant for shared objects — a regular application can't live directly under it — so Versus places Common-partition virtual servers in a dedicated AS3 partition. This also means an AS3 deploy never reconciles (or removes) the non-AS3 objects already inCommon: your existing tmsh-managed config is never touched by a conversion. Because a BIG-IP won't let two virtual servers share a VIP, deploying an AS3 copy is a migration (cut the app over to AS3), not a way to run an AS3 shadow of a live tmsh VS on the same address.
Converting is half the story; the operational half is changing a service safely. Versus ships an App Builder form, Modify F5 Virtual Server, that does exactly this and is driven entirely by the device's real data:
Submit, and the bound workflow runs the change end-to-end and visibly:
| Step | What it does |
|---|---|
| Git Pull | Sync the AS3 repo (collector-routed) so you're editing the latest. |
| Apply changes | Patch the VS's AS3 file with your pool / persistence / monitor edits. |
| Push to Git | Commit and push the updated file — the repo now records exactly what changed and who changed it. |
| Deploy to device | Send the committed declaration to the BIG-IP's AS3 endpoint. |
There is no tmsh, no playbook, no site build — and because it's an ordinary workflow, you can put an approval or a ServiceNow change in front of the deploy.
You don't have to send anyone to the Versus UI. In the App Builder Form Designer, the ServiceNow Embed panel mints a permanent embed token and a ready iframe snippet:
<iframe src="https://<your-versus>/embed/<token>/" width="100%" height="760" frameborder="0"></iframe>
Drop that into a ServiceNow Service Portal catalog item. The embedded form submits directly to Versus with no additional sign-in — the token authorizes it — so a network engineer working a request in ServiceNow picks the device and VS, adjusts the pool or monitor, and submits. The same governed pull → apply → push → deploy workflow runs, and the AS3 change lands inside your existing ServiceNow change process. The F5 work happens behind the glass.
The embedded submission is the same code path as an in-app submission — it just arrives with a token instead of a session. The ServiceNow-embedded form is a first-class front door, not a cut-down one.
f5.as3_deploy step.