PostHog is an open source platform which includes everything developers need to build better products, including product analytics, session recordings, feature flags, experimentation, LLM observability, error tracking, and more. With a focus on fast iteration and responsiveness, PostHog ships new features rapidly, averaging 2-3 new products every quarter.
By implementing Depot, PostHog reduced their Docker build times from two-and-a-half hours to under three minutes, dramatically improving their ability to ship fast while maintaining stability and fast customer response. We spoke with Technical Lead Paul D’Ambra to learn how Depot transformed PostHog’s development pipeline.
The challenge
Around here, we say Posthog ships weirdly fast, and you can’t say Posthog ships weirdly fast if you’re waiting for an hour and 45 minutes.
PostHog’s engineering team is deeply invested in moving fast and delivering quickly to their users. “We aim for a very fast turnaround,” Paul told us. “We aim to be very responsive to our customers. Our ideal support interaction is to be able to say, It’s building right now, and it’ll be out in 30 minutes.”
Slow Docker image builds repeatedly threatened that responsiveness, however, and became a growing bottleneck for the PostHog team. Paul highlighted the time cost of slow builds for the team, as well as the way that they induced that feeling of not getting anything done because of constant context switching.
“It’s so common it’s a cliche,” he said. “CI is slow, and so while you wait, you do something else.”
Not only were the builds slower than PostHog wanted, but the complexity of trying to optimize their Docker configuration to make them faster was daunting and time consuming. “Docker always seems like black magic to me,” Paul told us. “If you get the incantation just right, you have this tiny image. But make a silly mistake, and you end up with a much bigger image than you need – or your build will fail – and discovering why is difficult.”
The solution
There’s no reason for most people to visit Depot because they can just ignore the fact that the build is working. It always does the thing it’s supposed to do. For us, this is really good, because it’s a part of the system that we want to just work.
Depot’s performance, reliability, and hands-on support quickly won over the PostHog team. In fact, Depot’s impact on PostHog’s CI/CD pipeline was immediate and significant. The benefits included:
- Dramatically faster builds: PostHog’s Docker builds dropped from 17 minutes to just over 2 minutes.
- Hands-off stability: Once configured, Depot “just worked” in the background, requiring minimal ongoing attention.
- Proactive support: Depot’s team actively identified optimization opportunities, even reaching out to help reduce PostHog’s costs.
- Continual improvements: PostHog benefited from ongoing enhancements to Depot’s platform, further increasing their build efficiency.
Paul highlighted Depot’s proactive engagement, recalling instances where Depot’s team directly contributed optimizations to PostHog’s workflows. “Multiple times, we jumped into Slack and asked, Why is this like that? This might be broken, and we got back a PR into our repo.”
“In fact,” Paul continued, “once they messaged us in Slack and said, We realized you’re spending too much money – here’s the PR that will make you spend less money with us. Seeing another company with the same principles and the same values in that area – that’s the thing that sold me on Depot.”
The PostHog team also tested Depot’s GitHub Actions runner replacement and found it significantly faster than GitHub’s native runners. Since PostHog is an open-source product, “GitHub is essentially free,” Paul told us, and even then, PostHog moved forward with adopting Depot runners for their GitHub Actions. “We’re swapping money for developer time because it’s always a good investment,” he said.
The measurable impact
The most expensive mistake we can make as an engineering-driven company is slowing engineers down. Engineering time is a very valuable resource for us, and knowing that Depot is saving us time is super powerful.
With Depot in place, PostHog’s Docker builds are fast – startlingly fast, in fact:
- 55x faster Docker builds: Reduced from 193 minutes minutes to 3 minutes and 26 seconds.
PostHog also sees an average of 12-13% time savings for their GitHub Actions on Depot runners. Looking at an average two-week window where PostHod runs approximately 118,000 jobs, the team is saving around forty-four days of build time.
As Paul mentioned, engineering time is a valuable resource, and PostHog is saving a lot of it with these build and runner speeds. “Given how many PRs we run each day,” Paul said, “even just a few minutes per PR translates to more engineer time.”
This equates to cost savings for the company, of course, but as Paul noted: reducing build duration by this magnitude “is amazing for us because it gives us that responsiveness” that the PostHog team is dedicated to providing for their customers.
Paul and the team have also been happy with the state of continuous improvement in Depot’s capabilities, especially as compared to native platforms like Docker. “You can see over 2022 through to 2023, to 2024, the stability of Depot improves as you all are building your product,” he said.
“And we’re just benefitting from that increase. As Depot improves, the PostHog build is getting better, and the Docker build is staying relatively flat.”
Looking ahead
As PostHog continues to scale, the team remains committed to maintaining a frictionless development experience and fast release cycles for their customers. With Depot’s continued improvements and strong alignment with PostHog’s values of speed, efficiency, and responsiveness, the team sees Depot as a critical part of their infrastructure moving forward.