CommonLit is a nonprofit that builds a rigorous literacy curriculum for schools focused on the English discipline.

The product started as something teachers used for extra test prep, homework, or to support students whose first language at home was not English. Over time, it has become a core curriculum that districts adopt at scale.

CommonLit is taking on textbook companies as its main competition.

They get heavy traffic during the school day, when students and teachers are active.

On the engineering side, they have a small, lean team. Everyone can deploy and everyone rotates on call.

The core product is a Ruby on Rails monolith with Sidekiq for background work.

When Geoff joined, CommonLit was on Heroku. They later became Heroku Private Spaces customers so they could keep their database inside the same VPC as their compute and avoid having a publicly accessible database.

After Heroku’s security incident in 2021, they moved to a different PaaS, where they had an “okay” time. The team was generous with them, but the custom changes needed to make everything work eventually created new issues.

Two things were especially painful and made them look for alternatives:

1. Deploy reliability during the school day

   CommonLit likes to deploy several times a day, including in the middle of the day when students are actively using the platform. On both Heroku and the other PaaS there were points where they had to stop doing this.

   Daytime rollouts caused visible blips. Even a small choke during a deploy hurt reliability and made shipping during business hours risky.

2. Lack of visibility when things broke

   On other platforms they tried, when a pod crashed they sometimes could see that it had crashed but had no insight into why.

   The team felt blind when debugging and that raised stress levels around incidents.

There were a few more constraints the solution they were looking for had to satisfy:

• High fidelity preview environments

  On Heroku, preview environments were a “killer feature.” Geoff was very reluctant to move to any platform that could not provide a preview environment for every pull request.

  For CommonLit, a preview environment is not a simple static preview like you might see on Vercel. For each branch they need a full copy of the app, Redis, Memcache, Postgres, and data to test with.

• Strict handling of student data

  Education in the US has tight rules around student data (i.e. you cannot put student data into QA and dev environments).

  CommonLit takes this seriously. They maintain synthetic districts with fake schools, teachers, and students for testing. Any preview setup has to support that pattern.

• Run in their own AWS account and VPC

  CommonLit uses Buildkite for CI and likes the model where you bring your own cloud resources and the platform orchestrates work on top. They applied the same idea to application hosting.

  They want to choose the exact compute instances they run and keep RDS in the same VPC as their application pods.

• Limited Kubernetes expertise on the team

  The platform should hide that complexity and let a small team ship product.

CommonLit moved to Northflank and now runs their Rails monolith and Sidekiq workers on Northflank in their own AWS account, inside their own VPC. They continue to use AWS RDS for managed databases, now sitting in the same VPC as their Northflank pods.

Geoff describes Northflank as “fulfilling the promise” of the platform as a service setup he had been looking for since leaving Heroku. In his words, Northflank is:

• “Extremely easy to use.”
• “Extremely reliable.”
• A platform where his team can mostly focus on “building stuff and not on maintaining and operating stuff.”

What they ❤️ about Northflank:

Preview environments are one of the main reasons they chose Northflank.

For each pull request, they:

• Spin up a full preview application on a custom subdomain. The branch name is included in the subdomain so engineers always know which environment they are in.
• Run Redis, Memcache, and Postgres as part of the preview.
• Sync synthetic data from a reference database into the preview database.

Because each preview has its own independent Postgres database, engineers can run data model changes, alter columns, and generally exercise the full range of database operations as if they were in production.

CommonLit also runs five staging environments. These are needed for external tools that can only talk to a fixed subdomain, for example Google Classroom grade sync.

Northflank’s templating system lets them define environments and pipelines as templates stored in Git. Config changes are tracked as commits. When they update one environment, they can cascade the change to all the others that share the same template.

Before this, on past platforms, config changes could be made quietly and then either forgotten or rolled back by accident. Now they have a clear record of what changed and when, which their auditors also like.

Northflank runs in CommonLit’s AWS account and VPC.

This gives them:

• Control over which EC2 instance types they use.
• The ability to keep RDS and application pods in the same private network.
• A clear answer for auditors and school districts about the paths that lead to the database.

Geoff calls out observability as an area where Northflank is “considerably better” than every other platform they tested.

On Northflank they can:

• See what is running.
• Understand why a pod crashed if something goes wrong.
• Inspect behavior without feeling blind.

This addresses one of the main complaints his team had about previous platforms, where they could see failures but could not see the cause.

Geoff says he is “hard pressed to remember” a production incident that was not caused by a mistake in their own code. Services run, and when something fails they know it failed and can see what happened.

This is a big change from earlier platforms where they had outages tied to deploys or platform changes.

On Northflank, they deploy several times a day, including during school hours. Deploys are “very smooth.” They do not see the request blips they had on Heroku and the other PaaS.

Given their high traffic, this is really important. They can deploy without worrying that a rollout will drop requests and interrupt classrooms.

The combination of reliability, observability, and clear config history has had a direct effect on how the team feels about operating their infrastructure.

They know:

• Where to look if something fails.
• How changes are tracked.
• That they can test risky changes in isolated preview environments.

Geoff says they feel “a lot stronger” about understanding how things are working and are less stressed, even when nothing is broken, because they trust that if something did break, they would be able to see what is going on.

Every engineer at CommonLit is full stack, can deploy, and takes on-call rotations. They interact with Northflank directly as operators of the cluster, without having deep Kubernetes knowledge.

This fits exactly what Geoff wanted: a PaaS that hides Kubernetes instead of turning his team into part-time cluster admins.

CommonLit runs a Rails monolith with a small engineering team, strict rules around student data, and pressure to stay online during the busiest school hours of the year. They needed a platform that let them focus on building product instead of maintaining infrastructure and worrying about deploys.

Northflank gave them exactly that.

Northflank fulfilled the promise of what I have been looking for in a platform-as-a-service setup since we left Heroku.

Deploys stay smooth even during peak traffic. Preview environments behave like production. Observability is strong enough that the team no longer feels blind when something breaks.

For CommonLit, the outcome is very direct: they can support students with a small team and stay confident that the platform underneath them is stable.

As Geoff put it, they now operate on top of a great product, and he’s really glad we’re operating it.