Can Campfire run on Laravel Cloud?

We just got early access to the Ruby runtime on Laravel Cloud. The first thing we wanted to know was not "does Hello World work". We wanted to know what happens when you point it at a real Rails application that somebody else wrote, with opinions of its own.

Campfire is the obvious candidate. 37signals released it under the MIT licence as once-campfire: a complete group chat product with rooms, direct messages, file attachments, search, push notifications and bots. It is actively maintained, it runs on Rails edge, and it is exactly the kind of software a small team would love to own instead of rent.

It is also built by people who have spent years arguing, loudly and well, that you should own your servers. Campfire was designed to run on a single machine you control, and the defaults show it. That makes it a great test. If it can be made comfortable on a managed platform, most Rails apps can.

What we expect to go wrong

We have read the source, but we have not tried anything yet. These are guesses.

SQLite, with nowhere to put it

This one we know about. Campfire runs on SQLite in production, with the database file sitting on the local disk. Laravel Cloud does not offer SQLite: the filesystem is ephemeral, so a database file would vanish on the next deploy. That means a move to Postgres.

It is not only a database.yml change. Message search is built on SQLite's FTS5 full-text index, with raw SQL behind it, so search needs rewriting for Postgres too. We also expect a few migrations written with SQLite in mind.

File storage that assumes a disk

Attachments go through Active Storage onto the local disk. On Cloud, those have to live in an S3-compatible bucket. Rails supports S3 out of the box, so in theory this is configuration. In practice, nobody at 37signals is exercising the S3 path for this app, because the whole point of it is that you don't need a cloud provider. We would not be surprised by something like thumbnails or image variants that quietly assume a file on disk, or an SDK default that an S3-compatible store doesn't like.

Everything in one container

Campfire starts the web server, a Redis server and a Resque worker pool side by side in one container. On Cloud those become three separate things: a managed Valkey (Redis-compatible) cache, a web instance and a background worker. We expect that split to be straightforward. What we don't know is whether Campfire makes assumptions about Redis that a managed, locked-down Redis won't allow.

Realtime

This is the one that decides everything. Campfire's live updates run over Action Cable websockets. Laravel Cloud's own websocket service is Reverb, which speaks the Pusher protocol, not Action Cable. So the question is whether an Action Cable connection can reach a Rails app through Cloud's edge at all. If it can't, messages would only show up on reload, and a chat app without realtime isn't a chat app.

Early-access rough edges

Ruby isn't on Cloud's public runtimes list yet. We expect to find out what the platform assumes about how apps start, what it injects into the environment, and which settings can only be changed in the dashboard.

What success looks like

Two people in two browsers, chatting in a room without refreshing, with attachments stored in a bucket and search working. The data should survive a redeploy. And we want the smallest possible diff against upstream, because the long-term idea is to offer this as a one-click install that keeps up with 37signals' releases.