The tech stack we use to build Lago

The tech stack we use to build Lago

Our users and peers often ask us what language and tools we use and why. Here are our answers.

As part of our selection process, we focus on (1) robustness and (2) engineering speed. This means that once we’ve identified a few suitable tools, we aim to make our decision quickly to get back to building asap.

Our engineering stack is a living organism, so it will keep evolving, but here is what we use at the moment:

Language: Ruby on Rails

We developed Lago in Ruby. There are many technical reasons for that and our team, which has worked on billing for 3 years, has 10 years of experience with this language.

Every year for the past 10 years, people ask whether Ruby is dead:

Ruby is not going anywhere: it’s popular, offers a fast learning curve and what we find attractive is the vast community of Rubyists we can hire as we grow.

In the future, we might develop other services in Python, Rust or Go.

NB: There are several clients available for Lago’s API: Curl, Go, Python, Node.js and Ruby (as of August 2022), see our API documentation here.

Hosting: Amazon Web Services (AWS)

It’s ‘AWS robust’, we used it before and let’s be honest, AWS offers generous perks to YC companies.

Container orchestration: Kubernetes

No brainer for microservices.

Abstraction layer for Kubernetes: Porter

‘Heroku in your cloud’

Porter is a YC company as well. The team is genuinely nice, super reactive and precise. But that’s not why we chose them: they were recommended by one of our advisors, who led big data infrastructure projects for incumbent banks and telecom companies in Europe. So we chose them on the spot.

A solid alternative is Qovery, their team is brilliant too. The team only ran into their product once we had already implemented Porter, but it’s a great product as well!

Error alerting system: Sentry

We used it before. It gets s*** done consistently, is easy to use and reliable. Their company philosophy is interesting too, check it out here.

Cloud monitoring: New Relic

We tried Datadog and New Relic, and opted for New Relic: the onboarding was simpler and their entry level plan was much cheaper.

VPN: Tailscale

We started with NordVPN. It’s a great VPN, but we only needed an internal VPN. Tailscale does exactly that, and it’s really ‘zero-config’. Tailscale will link to your domain name, so that every team member can easily connect to it. It makes onboarding new team members easier and allows us to save a lot of time on the configuration.

Backoffice: Active Admin

It ticks all the boxes:

  • Not a third-party app;
  • In the Ruby ecosystem; and
  • Quick set-up.

Our code repository: GitHub

GitLab could have been an option but GitHub is the standard for self-hosted code.

Documentation: Docusaurus

We looked at GitBook, Theneo and GitHub pages. We wanted to have both the product documentation and API reference in the same place, while having enough flexibility on the presentation and design. We view our documentation as a part of our product so it needs to reflect the UX and brand we’re building.

We’re very happy with Docusaurus! The only thing to be aware of is that it’s a self-hosted solution, so it requires some configuration.

Product analytics: Metabase

We used it extensively before. It’s flexible in terms of queries and can also be used by non-tech users. We opted for the self-hosted version.

Search bar in our documentation: Algolia

It was one of our users’ requests. Most people use Algolia without knowing it (e.g. on Hacker News and many other websites). Love the product and the team!

If you’re hesitating between different tools, we’ll be happy to share our experience with you!


Two hosting options, same benefits

Whether you choose the cloud version or decide to host the solution yourself, you will benefit from our powerful API and user-friendly interface.

Open source

The optimal solution for small projects.


The optimal solution for teams who want control and flexibility on cloud or self-hosted version.