Haven: a Rails private blog you host yourself, with accounts you create by hand
Self-hostable private blogging
At a glance
- What is it?
- Haven is an MIT-licensed Ruby on Rails blog engine aimed at sharing posts with a fixed circle of friends and family rather than the open web. Its deployment story is Docker-first, its user model has no signup, and its cost profile depends heavily on which of the four documented install paths you pick.
- Who is it for?
- Adopt Haven if you want a small Rails blog whose audience is a list of accounts you create yourself and you are comfortable running docker compose up on a VPS or a Raspberry Pi. Skip it if you need public reach, search visibility, or a blog for a company; the README points that audience at WordPress or Ghost instead.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Ruby, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Haven picks: sharing with named people, not with the internet
Most blogging software optimizes for reach. Haven optimizes for the opposite. The README describes it as a private blog application where you write what you want, create accounts for the people you want to share with, and keep up with each other through built-in RSS. The stated philosophy is privacy-first, and the README is explicit that this is for sharing with friends and family, not commercial endeavors, adding that a company blog probably wants WordPress or Ghost.
That framing decides the feature set. There is no self-signup, which the README justifies on spam grounds: with no public registration form, there is no place for unauthorized users to affect the site. The intended user is one person or a small group who wants a journal, photo log, or family update stream that never appears in a search index, and who is willing to administer the accounts themselves. The topics list on the repository adds raspberry-pi and decentralized-web, which tells you the maintainers expect small hardware and a federated-ish, RSS-based reading model rather than a single central service.
How the pieces fit: Rails app, admin UI, private feeds, and a built-in reader
Haven is a Ruby on Rails application, and the README treats the web interface as the control surface for everything: managing users, customizing the blog, and writing or editing posts with markdown and live preview. So the data flow is conventional Rails. Posts live in the application database, rendering happens server-side, and the browser receives HTML with custom CSS or fonts applied on top.
The two features worth separating are the outbound and inbound RSS paths. Outbound, the README says feeds are private, meaning each friend follows your blog through a feed URL that is not meant to be public. Inbound, Haven ships an RSS reader so you can follow other blogs and other Havens from inside the same app. That is a different architecture from a static site generator, where feeds are files written at build time and anyone with the URL can read them. Here the feed is served by a running Rails process that also knows about your accounts.
Two constraints follow from the README's low-bandwidth claims. Images are downscaled to reduce page load times, and there are no JavaScript frameworks, ads, or trackers. The trade-off is that media handling is opinionated: you get downscaling whether or not you wanted the original resolution preserved, and there is no documented setting in the supplied material to change that behavior.
Getting it running: docker compose up, then edit two env vars
The README recommends Docker above everything else, and even the Raspberry Pi section says to use the Docker installation method. The sequence is short. Clone the repository with git clone https://github.com/havenweb/haven.git, then cd haven, then run docker compose up. The app listens on port 3000.
The part that matters is configuration. The README instructs you to modify the env vars in docker-compose.yml to specify a different HAVEN_USER_EMAIL and HAVEN_USER_PASS, noting these are used to create your initial user and password on startup. That is the whole bootstrap: no setup wizard, no separate seed command. The included docker-compose.yml builds the image from source. If you would rather pull a prebuilt image, the README points to a standalone compose file in the deploymentscripts directory, and notes that images are published to the GitHub Container Registry.
The other documented paths are less comfortable. The AWS route uses a script: from the deploymentscripts folder, run ruby deploy-aws.rb <domain> "<email>" with your email in quotes because it is used for registering the HTTPS certificate. The README warns deployment can take 20 minutes, and that ruby cleanup-aws.rb <domain> tears down what the script created. It also documents one failure: a cannot load such file -- aws-sdk-ec2 (LoadError) error, fixed by gem install aws-sdk. The Heroku button exists, but the README is candid that it is for exploration only.
The Heroku path is a demo, and the README says so
This is the clearest limitation in the documentation. The Heroku install, in the README's own words, is meant for exploration and experimentation, because images uploaded to your Haven will usually disappear within 24 hours and the reader will not automatically update until you visit the reader page. Two separate failures are described: ephemeral storage for media, and a reader that only refreshes on page visit rather than in the background.
The cost picture also changed. The README originally noted the Heroku install should fall under the free tier, then added an update noting that Heroku is eliminating free product plans and that Haven on Heroku will probably cost around $16 per month. For a private blog aimed at a handful of readers, that is a poor ratio compared with the managed options the README lists at $2.40 to $5 per month, or with a small VPS you administer yourself.
The general lesson is that Haven's persistence model is not abstracted away. Where uploaded media lives depends on the platform, and the documentation does not present a storage backend you can point at object storage. If your host gives you an ephemeral filesystem, your photos go with it.
What Haven does not do, and when to pick something else
Haven has no public-facing growth features described in the material. No self-signup, no ads, no trackers, no JavaScript frameworks. If you want comments from strangers, analytics, or posts that rank in search results, this is the wrong tool, and the README says as much by redirecting company blogs to WordPress or Ghost.
A more interesting comparison is against a static site generator such as Jekyll or Hugo with a private feed. Those tools produce flat files you can host almost anywhere, and the content survives even if the toolchain rots. Haven takes the opposite approach: a running Rails application with a database, an admin interface, and per-user accounts. You gain account management, markdown editing with live preview, media downscaling, and an in-app reader without writing any code. You lose the ability to serve the site from a CDN as inert files, and you take on the operational burden of a database-backed application.
The other realistic alternative is a managed hosted Haven, which the README offers directly at havenweb.org/order.html, alongside third-party hosts PikaPods and Caliber Node. That is less a different tool than a different operations decision: someone else runs the Rails process and you keep the account list.
Maintenance cost, upgrades, and the MIT licence
Haven is MIT licensed, which is permissive: you can run it, modify it, and redistribute it, and the licence text itself imposes no fee. That is not legal advice, and it says nothing about the separate terms of whatever host you choose, including the managed Haven hosting sold by the maintainer. Read those separately if you go that route.
The repository shows no releases retrieved, so there is no versioned upgrade path documented in the supplied material. Practically, that means upgrades run through the source: pull the repository and rebuild, or pull a newer image from the GitHub Container Registry. The Docker path makes this cheaper because the compose file builds from source and the prebuilt image exists as an alternative. The AWS path is harder to reason about, because the deployment script provisions an EC2 instance and a Route 53 domain, and the README does not describe an update procedure for an instance already running. If you take the AWS route, plan to treat the server as something you rebuild rather than patch in place, and keep the cleanup-aws.rb script handy.
On the Rails side, the maintenance you inherit is the maintenance any Rails app carries: Ruby and gem updates, database migrations, and whatever the upstream project changes between your checkout and the next one. The README does not describe a migration or backup procedure, so verify that before you put anything you care about into it.
Editorial conclusion
Adopt Haven if you want a small Rails blog whose audience is a list of accounts you create yourself and you are comfortable running docker compose up on a VPS or a Raspberry Pi. Skip it if you need public reach, search visibility, or a blog for a company; the README points that audience at WordPress or Ghost instead. Before committing, verify two things in your own checkout: that the HAVEN_USER_EMAIL and HAVEN_USER_PASS values in docker-compose.yml produce a working first login, and that your chosen host persists uploaded media, since the Heroku path is documented as losing images within about 24 hours.
Community notes