HumHub: a PHP social network you install on your own server

What HumHub solves, and who ends up running it

HumHub is a self-hosted social network. The README describes it as software used primarily as a social network, knowledge database, intranet, or information and communication platform. That list is the honest scope: it is not a file sync service, not a chat product, and not a project tracker, though modules can push it toward some of those jobs.

The people who deploy it are usually the ones with a server already. An organization wants profiles, group spaces, posts, comments and notifications without handing member data to a hosted vendor. The README states the software is used in over 4,500 organizations worldwide and is available in over 30 languages, which tells you the target is organizational deployment rather than a single team's side project.

The four-part model in the README is the whole design in miniature. Users have profiles they can customize. Spaces are rooms for projects, departments or events. Content covers posts, wiki pages, media, appointments, events and tasks. Modules extend the rest. If your requirement does not map onto one of those four, HumHub is probably the wrong starting point.

How Users, Spaces and Content fit together

The permission model is the part worth understanding before you install anything. The README says network operators can create as many Spaces as needed and automatically map users into the desired Spaces, with an advanced permission and notification system that includes email summaries. So membership is not purely self-service: an administrator can place people into Spaces, and what a person can do inside a Space is governed by permissions rather than by a global role alone.

Content lives inside that structure. Users create posts, wiki pages, photo and video, appointments, events and tasks depending on their permission, and share them with members of their Space. Comments are multi-level, and there are features to report inappropriate posts. Content can be edited, deleted and archived, and the README notes that content, Spaces and members are findable through configurable filter and search functions.

Modules are the extension layer. The README puts the count at approximately 80 modules, installed and activated to configure the network to an operator's needs. The named examples include Advanced LDAP, RESTful API, Mass User Import, Calendar, Wiki, OnlyOffice, JWT SSO, Legal Tools, Translation Manager, Custom Themes and Custom Pages, Tasks, Gallery, News, Polls and Mail for Direct Messages. Note what that list implies: LDAP and SSO are modules, not core. If directory integration is a hard requirement, it is a dependency you add, not a feature you get.

Installing HumHub and getting to a first post

The repository is a PHP application managed with Composer, with a .env.example file at the top level that documents environment-based configuration. The README itself does not contain installation steps; it points to the documentation at docs.humhub.org for configuration options. Start from the repository, install PHP dependencies with Composer, then copy the environment template and edit it.

git clone https://github.com/humhub/humhub.git
cd humhub
composer install
cp .env.example .env

The .env.example file is the configuration surface. Its header warns that the file may contain sensitive information and that it must not be accessible via the webserver, with file permissions set securely. Settings are commented out by default, and the file says to enable one by removing the leading # character. Lines beginning with #-- are descriptions and should be left in place.

#--- Pretty URLs (Recommended)
HUMHUB_CONFIG__COMPONENTS__URL_MANAGER__SHOW_SCRIPT_NAME=false
HUMHUB_CONFIG__COMPONENTS__URL_MANAGER__ENABLE_PRETTY_URL=true

#--- Debug Mode
HUMHUB_DEBUG=true

The database is configured the same way, by uncommenting a block and filling in the connection details the example already shows as a template.

HUMHUB_CONFIG__COMPONENTS__DB__DSN="mysql:host=localhost;dbname=humhub"
HUMHUB_CONFIG__COMPONENTS__DB__USERNAME="humhub"
HUMHUB_CONFIG__COMPONENTS__DB__PASSWORD="secret"

Two more settings from the same file are worth knowing early. Module paths can be added with HUMHUB_CONFIG__PARAMS__MODULE_AUTOLOAD_PATHS, shown as ["/opt/humhub-modules"], which matters if you keep modules outside the application tree. Redis is optional and configured by uncommenting the redis block, including HUMHUB_CONFIG__COMPONENTS__REDIS__HOSTNAME, HUMHUB_CONFIG__COMPONENTS__REDIS__PORT set to 6379, and HUMHUB_CONFIG__COMPONENTS__REDIS__DATABASE. The same block shows session and cache can be pointed at Redis as well. The README does not walk through the web installer or a first post, so treat the documentation site as the authority for the remaining steps.

What the modular design costs you in practice

The README's claim that the software is extendable with approximately 80 modules is accurate as a description of the ecosystem, but it hides the real work. Each module is installed and activated separately. LDAP, SSO, the REST API and mass user import are all modules. That means capability is not a property of the core alone; it is a property of the set of modules you chose, at the versions you pinned, against the HumHub version you run.

This shows up in upgrades. The repository carries a CHANGELOG.md, a separate CHANGELOG-BS5.md, and migration guides named MIGRATE-BS5.md and MIGRATE-DEV.md. The existence of a dedicated Bootstrap 5 migration document tells you the frontend foundation changed at some point and that themes and customizations were expected to need attention. If you run Custom Themes or Custom Pages, that is your problem surface, not the core team's.

The release history is also worth reading literally. Recent entries include v1.18.5 as a stable release, alongside v1.19.0-beta.1 and v1.19.0-beta.2 published on the same day as the stable release in the case of v1.18.5 and v1.19.0-beta.2. A beta line running in parallel with stable releases is normal for a project of this size, but it means you should decide deliberately whether your production instance tracks stable or beta. The README does not document a rollback procedure, so plan your own before you upgrade.

Where HumHub is the wrong tool

If you need file synchronization and document editing as the primary function, HumHub is not that product. It has files and it has an OnlyOffice module, but the README frames the software as a social network, knowledge database, intranet or communication platform. Search interest in comparing it against Nextcloud reflects a real confusion: those are different categories, and picking HumHub for sync-and-edit will leave you assembling modules to approximate something else.

If you cannot run PHP and a database, or do not want to, stop here. The README gives no hosted option, and the .env.example file assumes you control the filesystem, the webserver configuration and the database credentials. The warning about keeping the environment file out of webserver reach is not boilerplate; it is the difference between a working deployment and a leaked one.

There is also a governance question the README does not answer. The repository's LICENSE file is present, and package.json declares "license": "AGPL-3.0", while the file list also includes LICENSE.AGPL-3.0-or-later and the repository metadata reports the licence as NOASSERTION. The README points to humhub.com/licences rather than stating terms inline. If you plan to modify and redistribute HumHub, or to offer it as a service, read that page and the LICENSE files yourself. Nothing here substitutes for that.

HumHub against Elgg and OSSN

The closest open source comparisons people search for are Elgg and OSSN, and the difference is mostly in what the core ships with. HumHub's README describes a core that already includes Spaces with an advanced permission and notification system, multi-level comments, content reporting, archiving, and configurable search, with roughly 80 modules on top for LDAP, SSO, the REST API and more. That is a fairly opinionated platform out of the box.

Elgg is the older, longer-running PHP social framework, and the practical distinction is orientation: Elgg has historically been a framework you build a social application on, while HumHub presents itself as an application you configure and extend. If your team wants to write substantial custom functionality against the core, a framework-first tool may fit better. If you want an intranet running this week and modules for the gaps, HumHub's framing is the closer match.

OSSN is the lighter-weight option in the same PHP space. The trade-off is the same one that runs through this whole comparison: a smaller core means fewer assumptions imposed on you and less to configure, but it also means more of the permission model, notification behavior and content workflow is yours to assemble. HumHub's answer is to make those decisions in core and expose them as configuration. Whether that is a benefit depends entirely on whether you agree with the decisions.

Licence status and what a HumHub upgrade actually involves

Treat the licence as something to confirm rather than assume. package.json declares AGPL-3.0. The repository root contains LICENSE and LICENSE.AGPL-3.0-or-later. Repository metadata reports the licence as NOASSERTION, which means automated detection could not settle it. The README defers to humhub.com/licences. The AGPL family carries network-use obligations that differ from permissive licences, and if you modify HumHub and let users interact with it over a network, that is exactly the scenario those terms address. Read the actual files and the licence page; this article is not legal advice.

Upgrade cost has two parts. The core is a Composer project with a CHANGELOG.md, so core upgrades follow a normal PHP application cycle. The module layer does not, because each module has its own release cadence against a HumHub version. Before upgrading, list the modules you have activated and check each one's compatibility with the target version. The presence of MIGRATE-BS5.md and MIGRATE-DEV.md in the repository signals that major internal changes have happened before and that custom themes and custom code were expected to need migration work when they did.

Maintenance activity is not in question here: the last push to the default branch was on 2026-09-20. That tells you code is moving. It does not tell you whether the specific module you depend on is moving at the same pace, which is the check that actually protects your deployment.

Editorial conclusion

Adopt HumHub if you run PHP infrastructure and need an intranet or community platform where users, Spaces and permissions stay under your control. Do not adopt it if you want a hosted product with no server work, or if you need a file-sync and office-suite platform rather than a social one. Before committing, check the licence page at humhub.com/licences, confirm which modules you actually need and whether each is maintained, and verify that your PHP and database versions satisfy composer.json.

Frequently asked questions

Official sources

1. humhub/humhub on GitHub
2. Issues
3. Project website
4. README
5. Releases