Armory and the art of the uneventful release

The most desirable event in a software company is often the one nobody notices. A new version goes live. Customers keep working. The engineers go home. There is no emergency meeting, no apology email, no executive discovering an unexpected interest in server logs. Armory built its business around making that small miracle repeatable.

For readers who have never deployed an application, think of changing a restaurant’s kitchen while dinner service continues. The customers want their meals; the engineers want a better oven. Nobody has volunteered to be the experiment. Armory’s territory was the awkward interval between finishing a change and trusting it with everyone’s experience.

The interviews before the machinery

In late 2016, Daniel R. Odio, Isaac Mosquera and Ben Mappen began a company that would commercialize Spinnaker, the open-source deployment platform associated with Netflix and Google. Its early premises were Odio’s garage in Belmont, California. The more useful founding detail is less photogenic: over 100 interviews, three months, and more than 400 pages of notes. Enterprise leaders repeatedly described difficulty delivering software safely, quickly and at scale, according to Odio’s account of the research.

That is a promising complaint because it contains competing demands. Speed alone is easy to advertise. Safety alone can mean refusing to change anything. Armory’s proposition required both, across organizations whose software was becoming more distributed and whose release procedures had acquired years of sediment.

Mosquera had already seen how an organization could mistake delay for control. In a 2018 account of a previous employer, he described engineering and operations divided by distrust. His first attempt to fix the situation failed because he tried changing it before gaining agreement. Surveying engineers made the problems a shared concern rather than one person’s accusation. The team then used deployment frequency as its guiding measure.

That experience matters to Armory’s outlook, but it belongs to Mosquera’s earlier workplace. It is no customer benchmark for Armory. Its transferable lesson is procedural: establish what people believe is broken before buying equipment to fix it. A new tool introduced into an old argument can give the argument a very expensive interface.

A seat belt for the release button

Armory’s core enterprise product was a licensed distribution of Spinnaker running in the customer’s Kubernetes cluster. Spinnaker supplied the deployment foundation; Armory added commercial capabilities and expertise. The product documentation distinguishes essential and optional premium plugins, rather than pretending every feature began inside Armory.

The distinction explains its place in the market. A platform team could operate open-source Spinnaker itself, or pay for an enterprise distribution and help. Armory addressed the gap between software being available and software being dependable inside a particular company. Its customers included organizations with complicated estates and little appetite for production surprises.

“It’s about having seat belts on while you’re driving really, really fast.”

Isaac Mosquera · 2018 LaunchDarkly meetup

In that canary-deployment talk, Mosquera described the uncomfortable human job of staring at dashboards and deciding whether to continue. Automated canary analysis gives that decision a more systematic basis. A limited deployment meets real conditions; measurements help determine whether to expand it or retreat.

This also puts a condition on the promise. If the selected measurements do not capture the failure customers actually experience, the canary may look healthy while the product is not. Automation can repeat a sound decision or an unsound one with equal enthusiasm. Somebody still has to choose the signals.

The pipeline has a permission problem

Armory’s deployment expertise extended beyond the moment of release. Its Pipelines-as-Code feature used a service named Dinghy to keep Spinnaker pipelines synchronized with definitions stored in repositories such as GitHub, Bitbucket or GitLab. Teams could reuse components and review changes to deployment instructions as code. The vessel’s name was modest; its cargo was consequential.

A pipeline is an instruction sheet with privileges. Change the sheet and you may change what reaches production. Harness’s Dinghy security guidance explains that repository permissions matter because the webhook does not pass through the GitHub user’s credentials in a way Spinnaker can use to establish those permissions. It recommends code ownership and branch protection requiring owner review.

Here is a practice a reader can copy: make the deployment definition somebody’s explicit responsibility, and require that person’s review when it changes. Version control is useful evidence. It becomes a stronger control when the right people must approve the version.

The Policy Engine supplied another layer, using Open Policy Agent to check pipeline changes, execution and authorization. Rules could turn a company’s requirements into repeatable validations. The operational qualification is beautifully plain: with no runtime policies set, no runtime policy enforcement occurs. Installing the engine does not write the rules.

Those details distinguish Armory from a generic promise to automate everything. Its value sat in the connections between permissions, pipeline definitions, policy and the deployment itself. They are tedious subjects until the morning they become the only subjects anyone wishes to discuss.

The machinery behind the machinery

The delivery system also needs tending. Armory offered managed Spinnaker in the customer’s cloud as well as self-hosted software. Its Scale Agent tackled a specific operational burden: keeping deployment infrastructure informed about Kubernetes. A lightweight service and Clouddriver plugin streamed cluster changes using Kubernetes’s watch mechanism. Private API servers could remain private, and service accounts defined what the system could do.

In 2022, Armory took another route toward less maintenance: Continuous Deployment-as-a-Service. AWS’s account of the launch described a Kubernetes-focused service with canary and blue/green strategies. Product manager Stephen Atwell said smaller teams were a focus because existing solutions had proved too complex. AWS SaaS Factory helped with architecture and design.

The company had to solve a practical obstacle: customers often kept Kubernetes clusters off the public internet. Its lightweight agent connected outward to the SaaS APIs. That let the hosted service coordinate deployments while the application infrastructure stayed with the customer.

The historical AWS Marketplace listing documented contract purchasing and a trial. The underlying business model was commercial software and service: licenses, premium capabilities, managed operations and support, with SaaS as another delivery model. A buyer’s cost calculation should include the people and infrastructure needed to operate the system, alongside its contract. A deployment product itself becomes one more production responsibility.

The specialist meets the platform

Armory attracted substantial backing. A $28 million Series B led by Insight Partners in 2019 funded development and commercial expansion. B Capital led a $40 million Series C in October 2020, when the company reported more than $82 million raised. Its ambition was to make sophisticated delivery accessible to large enterprises.

In 2021, Odio handed the CEO role to former Wind River CEO Jim Douglas and became chairman. His explanation emphasized bringing in deeper expertise as the company grew. He named Autodesk, Snap, LaunchDarkly and JPMorgan Chase among customers. Armory’s cultural vocabulary included a Crew and an expectation that people make room for expertise beyond their own.

On January 11, 2024, Harness announced it had acquired key Armory intellectual property and technology, with engineering and support roles joining it. The announcement committed to continued self-hosted support and offered a path toward the broader Harness platform.

TechCrunch reported an asset purchase price of about $7 million in cash. That figure describes the purchased assets, rather than a valuation of the entire company.

In April 2024, Harness introduced a Spinnaker-to-Harness migration tool. The direction was clear: help existing deployment work travel into a wider platform. Today, Armory’s main website redirects to Harness’s continuous-delivery offering; its documentation continues to describe the technology.

The commercial lesson is an interpretation, rather than a diagnosis of Armory’s internal finances: a specialist can solve an expensive problem and still face pressure to fit inside a broader purchasing decision. Customers buy working deployments, but they also buy support continuity, integration and fewer systems to manage. Armory’s history makes those concerns difficult to separate.

Its most useful idea survives the transaction. Make releases small enough to observe, give the decision rules a home, and assign responsibility before pressing the button. The ideal result remains delightfully unremarkable: the software changes, and dinner continues.