Skip to content
    Opafra
    Request access
    Comparison

    Do not re-platform onto another system you have to run.

    Salt is fast and its reactor model is genuinely good. The question worth asking is not whether Salt works, it is who maintains your salt-master, and what the next renewal conversation is going to look like.

    Nothing to install on a nodeNo master to operateDry run and approval in one flowPublished, flat pricing
    Day one

    What each one costs before it does anything.

    This is Salt's own install guide, reduced to the things you have to stand up before the first command runs. Free software and no cost are not the same statement.

    SaltStack
    1. 1Check the network ports the master and minions need between them
    2. 2Add the Salt repository and install the packages on the master
    3. 3Install a minion on every node you intend to manage
    4. 4Write the master and minion configuration files
    5. 5Start both daemons and keep them running
    6. 6Accept each minion's key on the master before it can be addressed
    7. 7Verify with a test ping across the fleet

    Six of those seven are things you keep owning. The master is a service with upgrades, and the minions are an agent on every node you add from then on.

    Salt install guide
    Opafra
    1. 1Add a server with its hostname and an SSH key
    2. 2Run a plan against it

    There is no master to stand up and nothing to install on the target. If the host already takes SSH, it is already reachable.

    Feature by feature
    CapabilityOpafraSaltStack
    Infrastructure you operateNoneSalt master, plus HA if you need it
    An agent on every nodeNoMinions, or salt-ssh
    PricingPublished, flatBroadcom enterprise agreement
    Event-driven reactorNoYes
    Speed at very large fleet scaleNoYes
    AI plan composerYesNo
    Approval gates before a runYesNo
    Time-limited access grantsYesNo
    Run-to-run diffYesNo
    The master

    The salt-master is the part nobody budgets for.

    Salt is fast, and the reason it is fast is architectural: minions hold a persistent connection to a master and commands fan out over a message bus rather than a fresh connection per host. At several thousand nodes that difference is real and it is why Salt earned its reputation.

    The master is also a service you run. It needs capacity, upgrades, TLS, and a key-acceptance workflow for every new node. If you want it to survive its own failure you are running more than one, plus whatever sits in front of them. When it is down, you are not running anything, which makes it exactly the kind of infrastructure that needs the on-call rotation you were trying to automate.

    Salt does ship salt-ssh for agentless operation, and it is a genuine feature rather than a checkbox. It is worth knowing what it targets from: the roster system reads flat files, directories, SSH config, known_hosts, a range server, an Ansible inventory, a network scan, or the master cache. Checked again in September 2026, there is still no cloud-provider roster in that index, so an estate that lives in EC2 or Azure is writing the glue that keeps a roster current.

    None of that makes Salt a bad choice. It makes it a choice with a standing operational cost, and the question is whether the speed you are buying is speed you actually need at your fleet size. Between twenty and five hundred hosts, it usually is not.

    After Broadcom

    What we can say, and what we are not going to claim.

    Salt arrived at VMware through the 2020 acquisition and at Broadcom through the VMware one. You will find no shortage of pages telling you what that means for your renewal. We are not going to be one of them, because we do not have a dated fact to put behind it and a comparison page that trades in impressions is worth less than one that admits the limits of what it knows.

    What we can say is structural and checkable. Salt as an open-source project is alive and the community is active. Enterprise Salt is sold by a company whose portfolio strategy is set well above the product, and the terms you get at renewal are a commercial conversation rather than a published number.

    If that uncertainty is what brought you to this page, the useful framing is not "is Salt in trouble" but "what would I do if the renewal doubled". If the answer is that you would be stuck because the master and the minions are load-bearing, that is worth knowing now rather than at renewal. Published, flat pricing is the part of our offer that speaks to it, and it is on the pricing page in full.

    The other side

    When SaltStack is the right choice

    • You lean on the event-driven reactor. That model is real and we do not replace it.
    • You orchestrate at a scale where Salt's speed is the point. We build for 20 to 500 hosts.
    • Your pillar and grains data drives substantial logic. It maps to environment variables and inventory metadata, but it is a migration, not a copy.
    • Your enterprise agreement is settled and you are happy with it.

    The question underneath

    Most teams looking at this page are not unhappy with Salt itself. They are unhappy about owning a master, its upgrades, and a renewal they no longer control. Agentless removes the first two outright, and published pricing removes the third.

    If that is not your situation, Salt is a perfectly good place to stay.

    Questions

    What people ask before switching

    Salt has salt-ssh. Is that not the same thing as agentless?
    It is genuinely agentless, and it is the closest thing in this comparison to what we do. Two differences worth knowing. First, salt-ssh is a mode of a product built around minions, so the documentation, the ecosystem and most of the tooling assume the agent is there. Second, its host list comes from a roster, and the shipped rosters are files, directories, SSH config, known-hosts, a scan and an Ansible inventory bridge. There is no cloud-provider roster, so an AWS or Azure estate means generating the file yourself.
    What happens to Salt under Broadcom?
    We are not going to pretend to know. What we can say is that renewal terms and maintainer churn are the reasons people tell us they are looking, and that this is a judgement about direction rather than a dated fact we can cite. Weigh it yourself; the rest of this page argues from operational burden, which you can check against your own estate today.
    Do my Salt states transfer?
    No. Opafra runs tools and commands over SSH rather than applying states, so an estate expressed as a large state tree with pillar data does not carry across. If that describes you and convergence is what you actually need, Salt is the better tool and switching is not obviously right.
    Salt is faster across thousands of nodes. Does that not settle it?
    At that scale, often yes, and the comparison table says so rather than hiding it. Salt's ZeroMQ transport against thousands of minions is genuinely fast and we do not match it. We build for estates in the tens to low hundreds of hosts, where the cost that dominates is not execution speed but the master, the minions and the person keeping both patched.

    Nothing to install. Connect a server and see.

    Request accessSee pricing