What is FlexVNF?

FlexVNF is the earlier product name for what is now the Versa Operating System (VOS). It’s the same underlying software – SD-WAN, routing, firewall, QoS, and analytics – on every form factor, physical appliances included. The name originated with VOS packaged as a virtual network function and survives in device login banners (“VOS (FlexVNF)”), CLI branding, Director’s product-type labels, cloud deployment tooling, and third-party VNF marketplace listings. Third-party marketplaces list the deployable image as “Versa FlexVNF”.

Key takeaways

• FlexVNF is not a separate product – it’s VOS under its internal name.
• Appears in appliance login banners and CLI branding.
• Cloud deployment tooling (e.g., Azure Terraform) names resources after it.
• Third-party SDCI marketplaces list the deployable VNF as “Versa FlexVNF.”
• Managed identically to any VOS device – no separate device type in Director.

On this page: Why it matters · How it works · Where does the FlexVNF name appear? · FlexVNF & the VersaONE platform · FAQ

Why is FlexVNF important?

Anyone who logs into a Versa appliance’s CLI, reads a device banner, or works through a Terraform deployment on Azure will run into the string “FlexVNF” before they ever see the term “VOS” spelled out. Without knowing the two names refer to the same software, that’s a plausible source of confusion – an operator might wonder whether FlexVNF is a different product, a legacy version, or a stripped-down variant.

It matters just as much outside Versa’s own tooling. Third-party software-defined cloud interconnect (SDCI) providers – Megaport and Equinix among them – catalog Versa’s deployable virtual appliance under the “FlexVNF” name in their marketplaces, not “VOS.” Selecting the wrong vendor package, or failing to recognize the FlexVNF listing as the VOS instance you intend to provision, can stall a cloud onramp deployment before it starts. Recognizing the name is a small but real prerequisite for working across Versa’s own documentation and its cloud-marketplace partners.

What is FlexVNF?

FlexVNF is the internal software name for VOS, displayed in the device login banner and CLI branding on Versa appliances and virtual network functions. It carries no separate feature set or release cadence – a FlexVNF-branded instance runs the identical VOS stack that powers physical Cloud Services Gateways, virtual appliances, and Controller nodes: SD-WAN, next-generation firewall, routing, QoS, multitenancy, and analytics integration.

The name traces back to VOS’s origins as a flexible virtual network function – software built to run as a VNF on generic compute rather than fixed hardware. That heritage shows up today mainly in branding artifacts: banners, CLI prompts, resource names in automation templates, and vendor-package labels in partner marketplaces, rather than in anything a network design has to account for.

Where does the FlexVNF name appear?

The FlexVNF label shows up in a handful of concrete places across Versa’s documentation. In device login banners and CLI branding, appliances and virtual network function instances identify themselves as FlexVNF at login, per the software’s internal naming. In cloud deployment automation, Versa’s Terraform templates for deploying a VOS device as a branch on Azure provision a resource group named Versa_FlexVNF_RG, a VM named Versa_FlexVNF, and run a flexvnf.sh cloud-init script – all naming artifacts of the same internal name. In third-party SDCI marketplaces, Megaport’s MVE catalog and Equinix Network Edge both list the deployable package as “Versa FlexVNF”; provisioning it creates what those platforms call a FlexVNF device, complete with a FlexVNF public WAN IP address. In gateway URL paths, SSO integrations – such as configuring Okta SAML for an SSE gateway – route through endpoints containing /versa-flexvnf/, for example a login-consumer URL used during identity-provider setup.

FlexVNF & the VersaONE platform

Wherever the FlexVNF name appears, the device behind it is a standard VOS participant in the VersaONE platform. A FlexVNF instance provisioned through an Azure Terraform template, a Megaport MVE order, or an Equinix Network Edge deployment still onboards to a Controller for SD-WAN fabric membership and is administered through Versa Director like any other appliance – Director does not carry a distinct “FlexVNF” device type or a separate policy model for it. The image itself deploys wherever a hypervisor or interconnect platform can host it: imported as a qcow2 disk image on a KVM host, provisioned as the “Versa FlexVNF” vendor package on Megaport MVE or Equinix Network Edge, or acting as the host VOS instance in uCPE deployments, where Director’s service-chain templates wire VLAN subinterfaces to third-party guest VNFs running alongside it. The practical upshot is that recognizing the name matters for reading logs, banners, Terraform variable names, and marketplace catalogs correctly; it has no bearing on how the device is designed, deployed at scale, or governed by policy once it’s part of the fabric.

Frequently asked questions

Is FlexVNF a different product from VOS?

No. FlexVNF is the internal software name for VOS, shown in device login banners and CLI branding. There is no separate FlexVNF product line, feature set, or release track – it’s the same software under a different displayed name.

Why does an Azure Terraform deployment reference “FlexVNF” resources?

Versa’s Terraform templates for deploying a VOS branch device on Azure name their resource group, VM, and cloud-init script after FlexVNF – the same internal branding that shows up in the device’s login banner and CLI.

Why do Megaport and Equinix list “Versa FlexVNF” as a vendor package?

Third-party SD-WAN and cloud-interconnect marketplaces catalog Versa’s deployable virtual appliance under its FlexVNF branding. Selecting that package provisions a VOS instance compatible with the software version you choose during ordering.

Does the FlexVNF name change how the device is managed?

No. A FlexVNF-branded instance onboards to a Controller and is administered through Versa Director exactly like any other VOS appliance or virtual network function – there is no separate management path.

Where might I encounter “flexvnf” in a URL?

In gateway SSO configuration. Identity-provider integrations, such as Okta SAML setup for an SSE gateway, use endpoints containing /versa-flexvnf/ – for example, a login-consumer URL entered when configuring the identity provider.

More on Versa

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about FlexVNF, these are worth looking at next.