Mobilizon

Last reviewed Sep 13, 2026 · 846 words

Mobilizon is the only serious self-hosted answer to Facebook Events and Meetup, and the honest verdict is that it works best when a real organisation runs it for real groups. A solo self-hoster who wants a calendar for 12 friends will find it heavy: Elixir release, PostgreSQL with PostGIS, a mail server for confirmations, and 1 GB of RAM before anyone posts an event. A cycling club, a union branch, a hackerspace or a city collective with 5 to 50 organisers gets something no closed platform offers: public event pages with no account wall, no ad tracking, and federation with the rest of the fediverse.

What it replaces, and what it refuses to be

Framasoft built Mobilizon around three objects: events, groups and discussions. An event has a page anyone can read without logging in, an ICS export, an RSS feed and an "add to calendar" button that works. A group has members with roles, a private discussion board, shared resources (links, pads, folders) and its own public event listing. Attendees can RSVP anonymously if the organiser allows it, which matters for people who will never make an account just to say they are coming to a repair café.

What it deliberately lacks is the social feed. There is no timeline, no likes, no algorithmic suggestions. That is the design, not a gap: the Meetup replacement argument is that events should be discoverable by place, date and category, not by engagement. If your members expect a stream to scroll, they will find it empty.

Federation is group-shaped, not person-shaped

Mobilizon speaks ActivityPub, but the unit of federation is the group and the event, not the individual profile. Followers of a group on one instance see its events on another. A Mastodon user can follow a Mobilizon group and get event announcements as posts, although the rendering is a plain note with a link rather than a proper event card. Search across instances works for events and groups you already know about; it is not a global directory.

The practical consequence for one operator: you do not need a large instance to matter. A 20-member instance for one town federates with the big public ones (mobilizon.fr, mobilizon.org, the German instances) and your events show up there. That is a better deal than a Facebook page with 200 followers and 4% reach.

The install is three services, not one

The pieces that catch people, in the order they bite:

• PostgreSQL needs the PostGIS extension (CREATE EXTENSION postgis;) because address search and the map are geo-aware. A stock Postgres container fails at migration time.
• Outgoing email is mandatory. Account confirmation, RSVP confirmations for anonymous participants and group invites all go by mail. Point MOBILIZON_SMTP_* at a real relay; local sendmail from a home IP lands in spam.
• Geocoding defaults to Nominatim. The public OpenStreetMap endpoint has a 1 request per second policy and will block an instance that leans on it. Use a mirror, an Addok instance, or accept slower address entry.

With Docker the image is framasoft/mobilizon listening on port 4000 behind your reverse proxy, with a persistent /var/lib/mobilizon/uploads volume. Bare-metal installs are an Elixir release plus a systemd unit, well documented at docs.joinmobilizon.org. Budget 1 GB of RAM; Elixir is idle-cheap but the BEAM VM reserves generously at start.

Moderation and the open-registration trap

Federated software attracts spam accounts within days of appearing on instance lists. Set MOBILIZON_INSTANCE_REGISTRATIONS_OPEN=false and invite organisers by hand, or leave registrations open and enable the approval queue. Reports arrive in the admin panel and you can suspend remote instances by domain. Anonymous participation is fine to leave on; it produces no accounts to clean up.

The bigger operational question is continuity. Framasoft has said it is stepping back from leading Mobilizon development and passing maintenance to the community, so releases have slowed at last check. The software is stable and the protocol is a standard, but if you need a vendor to shout at, there is none.

Who should run it, and who should just join one

Run your own if you are an organisation that hosts 10 or more events a year and wants control over the domain, the data and the moderation policy. Join an existing public instance if you are one organiser with one group; you get the same federation and none of the PostGIS. Groups can move between instances, though attendee lists do not follow, so pick a home before you build an audience.

What I'd do

For a club or collective: Docker Compose with Postgres plus PostGIS, an SMTP relay you already trust, registrations closed, one admin and 3 to 5 organisers with group moderator roles. Publish the group's public URL and its ICS feed everywhere you used to post a Facebook event link. For an individual with one meetup: create the group on an established instance and spend the evening you saved actually organising the event.