Roundcube Webmail: a PHP IMAP client you host yourself

What Roundcube replaces, and for whom

Roundcube Webmail is a browser-based multilingual IMAP client with an application-like user interface. The README lists the expected client features: MIME support, an address book, folder management, message searching and spell checking. It is a client, not a mail server. Mail still lives on an IMAP server, and Roundcube reads and writes it over IMAP.

The audience follows from that. If you run a mail server and want a web interface your users can open in a browser, Roundcube is aimed at you. If you only want a mailbox and have no server, it is the wrong layer entirely: there is nothing to install it onto. The README also states that the code runs on a webserver and is mainly PHP and JavaScript, so whoever deploys it needs control of a PHP host and a database.

The PHP framework, the IMAP library and the plugin API

The architecture is stated plainly in the README. The code designed to run on a webserver is mainly written in PHP and JavaScript. It includes a custom framework with an IMAP library derived from IlohaMail, and it requires a set of external libraries listed in composer.json and jsdeps.json. That split matters: composer.json covers PHP dependencies, jsdeps.json covers the front-end libraries, and the repository ships a bin/install-jsdeps.sh script that the Makefile calls during release packaging.

Data flow is conventional for a webmail client. The browser talks to PHP on the webserver, PHP talks IMAP to the mail server, and a database holds the parts that are not in the mailbox. The README names MariaDB, MySQL, PostgreSQL or SQLite as the supported databases. The repository layout reflects the same division: program/ holds the application code, skins/ holds the user interface themes, plugins/ holds extensions, SQL/ holds the schema, and installer/ holds the web installer. The README describes the plugin API as the extension point and notes that the user interface is fully customizable using skins. Those two directories are where customization is expected to happen.

Installing Roundcube Webmail and getting to a first login

The README does not carry install commands. It says that for detailed instructions on how to install Roundcube webmail on your server, you should refer to the INSTALL.md document in the docs directory, and that upgrades follow docs/UPGRADING.md. Those two files are the authoritative source, and the steps below are only the entry points the repository itself exposes.

Start by placing the code on a PHP webserver and running Composer for the PHP dependencies. The Makefile fixes the PHP platform version at 8.1 for release builds, which is a signal about the version the project builds against, not a support statement for every deployment.

composer install --no-dev

The front-end libraries are separate. The repository provides a script for them, and the Makefile invokes it with a force flag during packaging.

bin/install-jsdeps.sh

Configuration lives in the config/ directory. The README points at the installer for setup, and the repository has an installer/ directory alongside config/ for exactly that purpose. Open the installer in a browser, point it at your database, and it writes the configuration. Expect to supply the database connection and the IMAP host your users will authenticate against. Once the installer completes, remove or restrict access to the installer directory; the README does not spell out that step, but leaving a web installer reachable on a production host is a decision you make, not one the project makes for you.

The snapshot warning is the first real constraint

The README opens with an attention block: this is just a snapshot from the GIT repository and is not a stable version of Roundcube. It states that replacing an existing installation with this version is not recommended, and that using a separate database for this installation is highly recommended. Read that as a deployment rule. If you clone the master branch, you are running unreleased code, and the project says so before it says anything else.

Stable use means release artifacts, not the branch. The releases listed for the project follow semantic versioning, and the README points to docs/RELEASE_MANAGEMENT.md for the details of that policy. Two maintenance lines are visible in the release list: a 1.7 series and a 1.6 series, each receiving patch releases. That is the shape of the upgrade cost. You pick a line, you follow its patch releases, and you read UPGRADING.md when you cross a version boundary. The README does not document rollback, so plan the database backup yourself before an upgrade rather than assuming a documented path back.

The second constraint is environmental. Roundcube needs a webserver, PHP, a database, and network access to an IMAP server. The README inherits browser support from jQuery 3.x and lists Chrome, Edge, Firefox including ESR, Safari and Opera, each at the current or current-minus-one version. Older browsers are outside that statement.

Skins, plugins and the GPL exception

The licence is GPL-3.0, and the README carries an exception: plugins and skins which merely make function calls to the Roundcube Webmail Software, and for that purpose include it by reference, shall not be considered modifications of the software. The README also notes that the GPL applies with exceptions for skins and plugins, and links to roundcube.net/license for the details. What that means in practice is that writing a plugin or a skin is treated differently from modifying the core, which is the usual reason an exception like this exists. It does not mean plugins are unlicensed. A third-party plugin or skin carries whatever terms its author set, and the exception in the README does not reach it. Check each one you install. This is a description of what the licence file says, not legal advice; if the distinction matters to your organisation, read LICENSE.md and the licence page rather than this paragraph.

There is a practical cost hidden in the plugin model too. The plugin API is the extension point, which means anything the core does not do has to come from a plugin, and a plugin has to keep working across releases. The repository's own plugin directory is the reference set for what ships with the project.

Roundcube compared with a hosted webmail service

The realistic alternative for most people asking about Roundcube is not another self-hosted client. It is the webmail that comes with their mail provider, or a hosted service where someone else runs the software. The difference in approach is where the software lives. Roundcube is code you place on your own webserver, wired to your own database and your own IMAP server. A hosted webmail is an account you log into, with no PHP, no schema and no upgrade path on your side.

That trade is the whole decision. Self-hosting gives you control over the interface, the skins and the plugins, and it makes you responsible for the PHP runtime, the database, the installer directory, and every patch release. A hosted service removes all of that and removes the control with it. Roundcube is the right answer when the mailbox is already yours and the missing piece is a browser interface. It is the wrong answer when the mailbox is somebody else's and you were only looking for a login page.

Who should adopt it and what to verify first

Adopt Roundcube if you operate a mail server or manage the host it sits on, you are comfortable running PHP and one of MariaDB, MySQL, PostgreSQL or SQLite, and you want the webmail layer to be something you configure rather than something you rent. The plugin API and skins give you a path to change the interface without forking the core, and the GPL exception is written with that path in mind.

Do not adopt it if you have no server to put it on, if you need a mobile application (the project is a browser client), or if you want a managed service. Do not deploy the master branch as a replacement for a working installation; the README states that this snapshot is not a stable version and does not recommend it.

Before you commit, verify four things against the repository. Read docs/INSTALL.md end to end and confirm your PHP version against composer.json. Read docs/UPGRADING.md and decide which release line you will follow, since the project maintains both a 1.7 and a 1.6 series. Check the licence terms for any skin or plugin you plan to install, because the exception covers plugins and skins that call the software by reference, not their own licensing. And confirm your browser floor, since support is inherited from jQuery 3.x and stops at the previous major version.

Editorial conclusion

Adopt Roundcube if you run your own mail server or control the host and want a webmail front end that talks IMAP directly, with plugins and skins as the extension path. Do not adopt it if you expect a managed service, a mobile app, or a drop-in replacement for a mail server: it is a client, and the README states the master snapshot is not a stable version and should not replace an existing installation. Before committing, read docs/INSTALL.md and docs/UPGRADING.md in the repository, confirm your PHP version against composer.json, and check whether the skins and plugins you need fall under the GPL exception or carry their own terms.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. roundcube/roundcubemail on GitHub