Deploy textlog

Deploy and Host textlog on Railway

textlog is a small social text log. Notes are capped at 280 characters, people follow each other and follow hashtags, and conversations happen in replies. There is no algorithm, no engagement score, and nothing pushing you to build an audience. It is one Bun process writing to a SQLite file, which makes it about as cheap and as simple as a social site gets.

About Hosting textlog

Hosting textlog means running a single container and giving it a disk. Everything lives in one SQLite file: accounts, notes, follows, hashtags, reports. There is no separate database service, no cache, no queue, and no object storage, so there is nothing to wire together and nothing to keep in sync. The container also draws its own link preview images, so the only outside services it ever talks to are the two optional ones you choose to add.

Sign-in is by emailed link, with no passwords anywhere. That normally means an email provider is mandatory before the very first account can exist, which is a miserable way to start. This build prints the sign-in link to the service logs when no provider is configured, so you can create your own account on a brand new instance, look around, and only add email later when you actually want other people to join. Only someone who can already read your Railway logs can use that link.

Common Use Cases

• A private notes-to-self log with an RSS feed, running for one person for pennies a month.
• A small shared space for a team, a group of friends, or a community, without handing the conversation to a platform that will change the rules later.
• A microblog attached to your own domain, where the posts stay yours and the whole archive exports to a file whenever you ask for it.

Dependencies for textlog Hosting

• A Railway volume for the SQLite database and its daily backups.
• Nothing else. No Postgres, no Redis, no S3.

Deployment Dependencies

• Upstream project: https://github.com/stagas/textlog (AGPL-3.0)
• Image source, with the self-hosting changes: https://github.com/hmseeb/textlog-railway
• Resend, optional, only if you want real sign-in emails: https://resend.com
• OpenAI, optional, only if you want automated checks on new notes: https://platform.openai.com

Implementation Details

Your first sign-in. There is no seeded admin and no default password.

1. Answer ADMIN_EMAILS at deploy time with the address you intend to use.
2. Open the public URL, go to /enter, and type that same address.
3. Open the service's Logs tab, find the block headed textlog email (no email provider configured), and copy the link inside it.
4. Open the link, pick a handle, and post.

What is already configured. APP_URL follows your Railway domain, the listener is on :: because Railway reaches containers over IPv6, the database sits at /data/textlog.sqlite on the volume with daily backups beside it in /data/backups, and a long random salt is generated once for the rotating visitor pseudonyms used in rate limiting. Automated content checks are off.

Adding email, which is the moment your instance becomes public. Set RESEND_API_KEY and EMAIL_FROM together; setting one without the other makes the app refuse to start, deliberately, so a typo cannot silently break sign-in. The from address must be on a domain you have verified with Resend. From that point anyone can sign up, so check that ADMIN_EMAILS is really you first, and consider setting OPENAI_API_KEY with MODERATION_DISABLED=false.

Custom domains. Add the domain in Railway, then update APP_URL to match and redeploy. Every sign-in link is built from APP_URL, so skipping that step sends people to the old address.

Backups. A backup is written daily and kept for 14 days, plus one taken automatically before any schema migration. They sit on the same volume as the database, which protects you from a bad upgrade but not from losing the volume, so snapshot it if the content matters.

Troubleshooting. A green deploy where every page returns 502 means HOST is not ::. Sign-in links pointing somewhere wrong means APP_URL does not match your domain. A crash-loop right after an edit usually names its own cause in the logs: one half of the Resend pair, or moderation switched on with no OpenAI key.

Differences from textlog.cc. Upstream is written for one specific server. It hardcodes that server's operator as the only administrator, and it refuses to start in production without a Resend key. This build reads administrators from ADMIN_EMAILS and starts without an email provider. Nothing else in the application was changed, and the upstream test suite still passes.

Why Deploy textlog on Railway?

Railway gives this the two things it needs and nothing it does not: one container and one persistent disk, with a public HTTPS domain attached automatically. Because there is no database service to pay for, an instance for one person or a small group costs about as little as hosting gets, and it scales by moving to a bigger container rather than by adding moving parts. Backups, logs, and the sign-in link you need on day one are all in the same dashboard.