Telesink is a real-time event feed, so the core experience has to feel instant. If an event comes in, it should show up. No refresh. No waiting. No “maybe the dashboard will catch up in a few seconds.”
This makes it different from Telebugs. Telebugs can tolerate the occasional refresh. Telesink cannot. It needs to feel like something alive on the screen.
Requirements I’m optimizing for
- Real-time updates without refreshing the page
- Fast iteration so I can ship quickly as a solo developer
- No over-engineering, especially before the product has real usage
- Open source and self-hostable from day one
Framework: Rails
My default choice is Ruby on Rails. I know it well, it lets me move fast, and it gives me a lot of boring decisions for free.
I have built Go services before, and Go is great for certain problems. This is not one of those problems. The first version of Telesink needs to be a reliable live feed, not an architecture showcase.
Database: PostgreSQL
I love SQLite and use it in many personal projects, including Telebugs. It is small, portable, and forces good habits.
For Telesink, I am choosing PostgreSQL. Event ingestion and broadcasts need reliable concurrency, and PostgreSQL is simply the safer default here. It also works well with the Solid libraries I want to use.
Self-hosting will include PostgreSQL in the container setup. One path, one expectation, fewer surprises.
Background jobs, caching, and real-time: the Solid trifecta
I am staying Redis-free and leaning into the Solid family of libraries. They are defaults in modern Rails, and they fit this project nicely.
- Solid Queue for background job processing
- Solid Cache for fast, database-backed caching
- Solid Cable for real-time WebSocket broadcasts
All three store state in PostgreSQL. That means fewer moving parts and less operational ceremony. For an early-stage product, that matters more than theoretical scaling stories.
Architecture: one repo, no Rails engines
Everything lives in one Rails app. No engines, no clever package split, no fake boundaries.
I want the codebase to stay easy to read while the product is young. SaaS-specific pieces like billing and multi-tenancy can come later, when there is enough pressure to justify them.
Frontend: Hotwire, Turbo, minimal JavaScript
Hotwire and Turbo give me the app-like feel without turning the whole thing into a SPA. Stimulus is there when I need it, but I want as little custom JavaScript as possible.
Styling is plain CSS plus Tailwind, the same combination that has worked well for me on Telebugs.
Authentication
I am starting with Google Sign-In on top of Rails’ built-in authentication. It is low-friction, secure enough for the first version, and does not ask me to invent my own auth story.
Event ingestion
The Rails app exposes API endpoints for signed POST requests. Each sink gets its own key. Rate limiting, validation, and retry behavior can grow as the product gets real usage.
Deployment: Kamal on Hetzner
I use Kamal and Hetzner a lot, so that is where I am starting. It is cheap, reliable, and boring in the best way.
For self-hosting, the goal is the same shape: a simple container setup with PostgreSQL included.
Error tracking
I will dogfood Telebugs for exception monitoring. Obviously.
Conclusion
Telesink is fully open source. The complete codebase is available at https://github.com/telesink.
That is the plan for now. It is pragmatic, built on tools I know, and deliberately minimal. Self-hosting will stay free. The hosted version can become the convenient paid option for people who do not want to run it themselves.
Follow along on X at @kyrylo.