Katara has evolved a lot since we first launched in September 2025. We were a complete Ruby on rails shop from frontend to back but few things have changed since. This article will take you through how we have been building katara. We choose rails because we are a Ruby bunch. Ruby is just so nice to write and read. Rails has really grown as a framework, so many libraries (gems) that help small teams to build and validate an idea.
Let's first take you back to how we built things at first launch. Hotwire on the frontend with rails erb (partials all the way). Why you ask? Well, we loved the simplicity of having to write Ruby on the frontend, everything is so well gelled together. Everything else around development was Rails centered. Kamal to deploy to our server postgres for our database and we dockerized our app before we could run it.
How we are building katara now
We are still using rails, we may never move away from it. All of katara's business logic, database interactions and routing are still handled with rails. What changed then? Our frontend did, we moved to inertia with svelte 5 as our new frontend framework. Svelte felt like a breath of fresh air for our frontend. No clunky javascript wiring with erb files, we can move to component-based developement as parts of the system became complex (On the frontend mostly). Inertia reduced the complexity of building a separate API service for our svelte frontend. We can write everything in rails included page rendering and just render componenets with svelte.
We are serializing data with the OJ Serializer gem which is built on top of the OJ gem. We chose not to use the default ActiveModel::Serializer. As Katara grows, we wanted a serialization approach that gives us more control over how data is prepared and passed to the frontend, while keeping serialization lightweight.
What didn't change
Well as we moved to inertia, certain things stayed the same (mostly everything else stayed the same).
We still use Docker to containerize the application and kamal for deployment which is triggered with our github actions pipeline with PostgresSQL as our db of choice and everything is fully running entirely on Digital Ocean droplet and managed PostgreSQL database.
What we would love to change
One thing that stands out at the time of writing this article is our CI/CD pipeline. GitHub Actions worked really well for us when we were starting out. It was simple to set up, easy to understand, and gave us everything we needed to get our deployments running. As Katara has grown, however, we've started to feel some of its limitations. Our pipeline has become more complex, and we've been seeing inconsistencies that we'd like to address. We're currently evaluating alternatives such as Buildkite and CircleCI to see if they can give us a more reliable and predictable CI/CD experience. We're still early in that process, so we haven't made a final decision yet. For now, GitHub Actions continues to run our pipeline, but CI/CD is definitely one part of our stack we're looking to improve as Katara continues to grow.
Summary
- Ruby on Rails — backend, business logic, routing
- Svelte 5 — frontend
- Inertia Rails — Rails/Svelte bridge
- OJ Serializer + OJ — serialization
- PostgreSQL — database
- Docker — containerization
- Kamal — deployment
- DigitalOcean — infrastructure
- GitHub Actions — CI/CD (for now)