Telesink

Tech choices and trade-offs

/ Kyrylo Silin ~ X · Bluesky · Mastodon

Telesink is a real-time event feed. The core experience has to feel instant. There should be no page refreshes and no noticeable lag. Events should appear as they happen. The goal is something closer to Telegram bots or Slack, Discord, or Teams webhooks that notify you the moment something important occurs, but presented in a clean, dedicated dashboard instead of being lost in chat noise.

Unlike Telebugs, which can tolerate occasional refreshes, Telesink cannot. It needs to behave like an app that is always live.

Requirements I’m optimizing for

Framework: Rails

My default choice for almost everything is Ruby on Rails. It is battle-tested, I know it well, and it lets me move very fast. I have built Go services before and they work well for certain problems, but Rails wins here thanks to its conventions, ecosystem, and built-in tooling.

The immediate goal is a solid MVP that does one thing well, showing a live feed of events. It does not need to be pretty or feature complete yet. It just needs to be reliable and real-time.

Database: PostgreSQL

I love SQLite and use it in all my personal projects, including Telebugs. It’s lightweight, enforces discipline, and is incredibly portable. That said, PostgreSQL is the better fit here. It handles concurrency extremely well, which is important for real-time event ingestion and broadcasts. It has rock-solid reliability and integrates perfectly with Rails and the Solid trifecta. Self-hosting will include a containerized PostgreSQL instance for consistency and simplicity. There is no need for separate database paths or managed services.

Background jobs, caching, and real-time: the Solid trifecta

I’m staying Redis-free and leaning fully into the Solid family of libraries, which are now defaults in Rails 8+.

All three store state directly in PostgreSQL, require zero additional services, and have proven extremely reliable in my other projects. For an early-stage product, this keeps operations and deployment dead simple while still delivering the real-time feel that’s core to Telesink.

Architecture: one repo, no Rails engines

Everything lives in a single monorepo. This prioritizes development speed and keeps the codebase easy to understand. With PostgreSQL and the Solid trifecta, the same code works seamlessly for self-hosted instances from day one. SaaS-specific features, such as billing and multi-tenancy, can be added later when there’s demand.

Frontend: Hotwire, Turbo, minimal JavaScript

Hotwire and Turbo drive the reactivity, giving that instant app-like feel without a full SPA. JavaScript is minimal and only handled with Stimulus when truly necessary.

Styling is plain CSS plus Tailwind, the same combo that worked great on Telebugs.

Authentication

Google Sign-In paired with Rails’ built-in authentication system. It’s secure, low-friction for users, and requires almost no custom code.

Event ingestion

The Rails monolith exposes API endpoints for receiving events via signed POST webhooks, authenticated with per-feed API keys. Rate limiting, validation, and retry handling will be added incrementally as needed, keeping the MVP lean.

Deployment: Kamal on Hetzner

Deployment is handled with Kamal to a Hetzner cloud server, which provides inexpensive, reliable hardware with painless container orchestration. Self-hosting uses the same Kamal config, or a simple Docker Compose alternative, with a containerized PostgreSQL instance.

Error tracking

Dogfooding Telebugs for exception monitoring.

Conclusion

Telesink is fully open source. The complete codebase is available at https://github.com/telesink.

That’s the plan for now. It is pragmatic, built on tools I know deeply, and deliberately minimal while prioritizing a smooth open-source self-hosted launch. Self-hosting will remain free forever, while the long-term goal is a convenient paid SaaS version for those who prefer a hosted solution. Updates will come as things progress. Follow along on X at @kyrylo.