A Movim container needs PostgreSQL and still an XMPP server

Movim is a frontend, XMPP is the transport underneath

The one-sentence definition matters: Movim is a federated blogging and chat platform that acts as a web frontend for the XMPP protocol. That is a different proposition from building a social network on its own protocol, and it decides most of what you can expect. Federation is inherited from XMPP rather than reimplemented, so an account on one instance can reach people on another through the server infrastructure rather than through a bespoke federation protocol. Chat is likewise XMPP rather than a side channel, which is why the project describes itself as both blogging and chat rather than as one or the other. The repository is PHP, with composer.json and composer.lock at the root, a daemon.php entry point, a workers/ directory for background processing, database/ for the schema, phinx.php for migrations, public/ for the served assets and app/, src/ and config/ for the code. The presence of a separate daemon is the first hint that this is a multi-process application.

The quick test is Podman, and it is explicitly not a deployment

There is a test path short enough to try in an afternoon, and it comes with a warning attached. The README recommends Podman and calls it a FOSS alternative to Docker that is available on all the main distributions. You install podman-compose, clone the repository, and run:

podman-compose up

After a few minutes you have a local test instance with a blank database, reachable in a browser at https://127.0.0.1:8443/. The port is worth noting because it is 8443 rather than 80 or 443, and the container serves a self-signed certificate, so the browser will warn and you have to accept it before the login page appears. The warning above the instructions says this setup is only for tests, that the containers are not optimized and that most of the caches are disabled, and it points to INSTALL.md for an actual deployment. That distinction is not pedantic: a container with caching disabled is a reasonable way to see the login screen and an unreasonable way to run a community instance.

The published image is not self-contained

The image is also published at ghcr.io/movim/movim:latest, and the sentence next to it changes the picture from the compose script: the image requires postgresql to run, with the reader pointed at the podman-compose script as the example. So the difference between the two paths is the database. The compose script assembles a stack including PostgreSQL, which is why a single up command gives you a working instance. Pulling the image and running it on its own does not, and you are expected to supply the database yourself. The repository makes that concrete in its build and config files: the image definition is a Containerfile rather than a Dockerfile, matching the Podman-first framing, and the compose file is podman-compose.yml. The environment example sets DB_DRIVER=pgsql with a host, port 5432, database name and credentials, which is a PostgreSQL-only configuration with no MySQL or SQLite alternative listed.

The daemon binds to localhost on port 8080 by default

Three separate processes make up a Movim deployment, and the defaults for each are in the environment example. There is the web application itself, served through whatever proxy you put in front of it. There is a daemon, configured by DAEMON_URL, DAEMON_PORT and DAEMON_INTERFACE, which the README comments describe as the port on which the daemon will listen and the interface on which it will listen, with the interface required to be an IP. Two booleans sit alongside them, DAEMON_DEBUG and DAEMON_VERBOSE. And there is the XMPP server, described in its own block. The ordering matters for a reverse-proxied setup: the daemon on 8080 bound to 127.0.0.1 is not reachable from outside the host, which is what you want if a proxy terminates TLS in front of it and the daemon does not listen on a public interface by default. DAEMON_URL is the public URL of your instance, so it is the value that ends up in the URLs other people are given, and getting it wrong means federation references point at a host only you can see.

Two daemons and an XMPP server are configured separately

The .env.example file is where the architecture becomes explicit, and it is short enough to read as a deployment checklist. The database block is PostgreSQL on localhost:5432 with a movim database and movim credentials. The daemon block sets DAEMON_URL to the public URL of your instance, DAEMON_PORT to 8080, and DAEMON_INTERFACE to 127.0.0.1 with a comment saying it must be an IP, plus DAEMON_DEBUG and DAEMON_VERBOSE flags. The third block is the one that surprises people: it is named Galener configuration and holds GALENER_XMPP_IP, GALENER_XMPP_PORT set to 5347, GALENER_XMPP_HOST, GALENER_XMPP_PASSWORD and GALENER_GALENE_PATH. So the XMPP server is an external component you run, listening on 5347, with its own hostname and password. The default daemon interface of 127.0.0.1 is a safe default for a reverse-proxied deployment and a wrong one if you expected the daemon to face the network directly.

Translations and instance discovery have their own files

Two smaller features in the repository tell you how the project is operated. Translation happens on Transifex, with the README asking for help there, and the compiled strings live in a locales/ directory in the tree rather than being fetched at runtime, which is the right arrangement for a self-hosted instance. Instance discovery has a doap.xml file at the root, which is the ActivityPub description document format, alongside the Mastodon account linked from the README and the XMPP chatroom at [email protected]. The About section also points at join.movim.eu, a page for joining one of the existing instances, and at movim.eu as the official site. Together those links describe a project with a public-facing network of instances plus a self-hosting path, rather than a library or a tool you embed.

Where Movim is the wrong choice

Four cases. The first is a single-binary or one-command install expectation. The environment file expects a database, a daemon on its own port and an external XMPP server on 5347, so this is a multi-component deployment even though the test path hides it behind podman-compose. The second is a content site that does not need federation. The XMPP dependency buys you federation and interoperable chat, and it costs you the operational surface that comes with running a server plus a database plus a daemon. If you only need posts that people read, that is a heavier design than the problem requires. The third is hosting on AGPL terms. The project is released under AGPLv3 with the terms in COPYING.txt, and any deployment where users interact with it over a network is exactly the case that licence was written for, so read it before you put it in front of anyone rather than after. The fourth is expecting the container to be production-ready. The README says the containers are not optimized and most caches are disabled, and points to INSTALL.md for real deployments, so the image is a starting point rather than the supported configuration.

Editorial conclusion

Movim suits a community that wants a self-hosted, federated space built on XMPP and is prepared to run a server-side stack rather than drop a file on shared hosting. It does not suit someone who wants a single-binary install, since the configuration expects PostgreSQL, a daemon on its own port and an XMPP server. Before adopting, read INSTALL.md rather than the container path, set DAEMON_URL and DAEMON_INTERFACE deliberately, and decide whether you are hosting a public instance or joining one listed on join.movim.eu.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. movim/movim on GitHub
3. Project website
4. README
5. Releases