{"id":31720,"date":"2026-01-26T22:33:21","date_gmt":"2026-01-26T22:33:21","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=31720"},"modified":"2026-01-27T11:22:14","modified_gmt":"2026-01-27T11:22:14","slug":"the-safety-of-speed-shipping-code-at-intercom","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/the-safety-of-speed-shipping-code-at-intercom\/","title":{"rendered":"The safety of speed: How we ship code 180 times per day"},"content":{"rendered":"

“Speed is not the enemy of safety; it is the prerequisite for it.”<\/p>\n

At Intercom, the average time from merging code to it being used by customers in production is just 12 minutes.<\/span><\/p>\n

In January 2026, we are averaging 180 ships per workday<\/strong> \u2013 roughly 20 deployments every hour. Conventional wisdom suggests that to increase stability, you must slow down. We believe the opposite. At Intercom, speed is not the enemy of safety; it is the prerequisite for it. Accumulating code creates risk; shipping small batches minimizes it. Shipping is <\/span>our company\u2019s heartbeat<\/span><\/a>.\u00a0<\/span><\/p>\n

Maintaining this frequency that fuels our product innovation, while targeting 99.8+% availability is a constant battle and has required over a decade of significant investment in systems, principles and processes. We protect the integrity of our systems through three distinct layers of defense: an <\/span>automated pipeline<\/b> that is simple, reliable and removes the need for manual intervention, a <\/span>shipping workflow<\/b> that promotes ownership and is flexible enough to provide guardrails that act as accelerants, and a <\/span>recovery model<\/b> optimising for mitigating inevitable failures. Here is how we’ve built each layer to ensure our velocity remains our greatest source of stability.<\/span><\/p>\n

While Intercom consists of various services and frontend applications, this post focuses on our <\/span>Ruby on Rails monolith<\/b>. It is our core application and the one we deploy most frequently; we also deploy it to three different data-hosting regions with independent pipelines. While our other services (such as our Intercom UI) follow similar pipeline principles and safeguards, the Rails monolith is the best example of how we ship code at our scale.<\/span><\/p>\n

\"ProductionDeployment_Fin\"<\/p>\n

The automated pipeline<\/span><\/h2>\n

Designed to move code from merge to production as fast as possible while enforcing strict safety checks, our pipeline is optimized for speed and safety and is entirely automated with the majority of releases requiring no human intervention.<\/span><\/p>\n

Build and parallel testing<\/span><\/h3>\n

The process begins when an engineer merges code to GitHub. Two things happen immediately:<\/span><\/p>\n