Roundcube Webmail is a pointer document with a real application attached

The master branch is a snapshot the project asks you not to deploy

The ATTENTION block at the top of the repository is unusually blunt. What you get from a clone is a snapshot from the GIT repository, not a stable version of Roundcube, and replacing an existing installation with it is not recommended. The same paragraph advises using a separate database for a snapshot installation. Both sentences matter more for people evaluating the software than for people installing a release, because the normal path leads to docs/INSTALL.md and the upgrade path leads to docs/UPGRADING.md, and the top level file describes neither. Tagged releases follow semantic versioning, with the process written up in docs/RELEASE_MANAGEMENT.md. The recent tags show why the distinction is practical: 1.7.5 and 1.6.20 both landed on October 19, 2026, and 1.7.4 arrived on September 6, 2026. That is two release lines shipping on the same day, so choosing a version becomes a decision about which line you intend to run rather than a question of which tag is newest. Point a webserver straight at a checkout of master and you are serving the development tip to real users.

Four database engines, and the installer ships inside the repository

Roundcube requires a database before it does anything, and it accepts four of them: MariaDB, MySQL, PostgreSQL, or SQLite. That choice is not a minor implementation detail, it determines what you configure in the config/ directory and what has to be applied from the SQL/ directory, and the repository ships an installer/ directory next to both, along with index.php at the top level and public_html/ as a separate directory. Other top level entries describe how the project is built rather than run: bin/, tests/, logs/, temp/, skins/, plugins/, composer.json, jsdeps.json, package.json, and phpstan.neon.dist. Seeing logs/ and temp/ as tracked directories tells you two writable paths are expected from a deployment. What the top level file does not give you is a command to run. It points at docs/INSTALL.md for detailed instructions on your own server, so the deployment recipe, including the values you configure and the database setup steps, lives in a document you have to go fetch. The project also keeps issue tracking on GitHub and a support page, and the developers are volunteers.

Browser support is inherited from jQuery 3.x, version by version

Roundcube states its browser support as inherited rather than chosen. The client uses jQuery 3.x along with other libraries, so the supported set is whatever jQuery carries, and the list is spelled out:

- Chrome: (Current - 1) and Current
- Edge: (Current - 1) and Current
- Firefox: (Current - 1) and Current, ESR
- Safari: (Current - 1) and Current
- Opera: Current

Two things fall out of that list. Firefox ESR is named separately from current Firefox, which tells you the long lived support channel is considered deliberately, while Opera is supported on Current only and has no previous release listed. Everything else tracks the previous and current release, so a browser that skips a version simply leaves the supported set. The package manifest pins the libraries the interface loads: jquery ^3.7.1, bootstrap ^4.5.3, tinymce ^5.10.9, codemirror ^5.58.3, and openpgp ^6.3.0, each under optionalDependencies rather than the main require block. The consequence for a deployment is that your browser policy ends up constrained by a transitive dependency rather than by a support decision the project authors made directly.

Skins and plugins are licensed outside the GPL by design

The licence text carries a carve out that is easy to skim past. Roundcube itself is free software under the GNU General Public License version 3, and the parenthetical in the licence line is with exceptions for skins and plugins. The mechanism behind it is stated directly: plugins and skins which merely make function calls to the software, and include it by reference, are not treated as modifications of it. Use the file in another project, or create a modified version that will not be part of Roundcube, and you may remove that exception and use the code under the original GPL terms. Everything else stays under the GPL with no warranty of any kind. Two practical consequences follow. Theme and plugin authors are not required to release under the GPL. And the dividing line is technical rather than legalistic: if your plugin copies Roundcube code into itself instead of calling into it, the exception stops applying and the plugin becomes a derivative work under the full GPL.

The Makefile cuts tests, dev dependencies, and CI metadata out of a tarball

Building a release here is a Makefile job, and the file states that it is used by developers to build release packages. The header fixes release identity before anything else runs:

GITREMOTE=https://github.com/roundcube/roundcubemail.git
GITBRANCH=master
[email protected]
VERSION=1.8-git
PHP_VERSION=8.1

VERSION=1.8-git, against a repository whose newest tags are 1.7.5 and 1.6.20, tells you where the trunk sits. PHP_VERSION=8.1 is handed to composer as a platform setting so dependency resolution for a package targets 8.1 instead of whatever PHP runs the build, and the build also branches on uname, using a different sed invocation on Darwin. The complete target copies the prepared repo into roundcubemail-$(VERSION), pins the composer version field, pulls in kolab/net_ldap3 at ~1.1.4 with --no-update --no-install, then unsets require-dev, autoload-dev, and repositories so nothing from a development checkout leaks into the output. It installs browser dependencies with install-jsdeps.sh --force, shrinks two named bundles, deletes jsdeps.json and the install script from the package, clears temp/js_cache, and strips tests and .git directories from the vendor tree. A release tarball is a deliberately thinned artifact, not a copy of the working tree.

composer.json, jsdeps.json, and package.json are three dependency graphs

Server and browser dependencies are declared in separate files and installed by separate tools. composer.json covers the PHP side, including the external libraries the application needs alongside its own framework and its IMAP library derived from IlohaMail. jsdeps.json covers the browser side, and the release build deletes that file after running install-jsdeps.sh, which is why it exists in the repository but not in a tarball. package.json adds a third declaration for build tools, split into two blocks. devDependencies carry eslint ^8.57.0 with eslint-config-airbnb-base ^15.0.0, eslint-plugin-import, eslint-plugin-unicorn ^54.0.0, less ^4.2.0, csso-cli, less-plugin-clean-css, and uglify-js ^3.17.4. optionalDependencies carry the runtime libraries a browser bundle may or may not need: jquery, tinymce, openpgp, codemirror, bootstrap, and a second less entry at ^4.1.3. The split is not accidental, but it does mean a contributor tracks three files, and the Makefile has to put node_modules/.bin onto PATH before any of those tools run. Linting config lives in .eslintrc.js and .php-cs-fixer.dist.php, with a fully qualified strict types variant alongside.

Nothing at the top level says how the client reaches your mail server

This is the gap to know about before you plan an install. Roundcube is described as a browser-based multilingual IMAP client with an application-like interface, MIME support, an address book, folder management, message searching, and spell checking. Every item in that list describes the reading experience. The top level file never names a transport setting, an IMAP host or port, a TLS or certificate option, an SMTP relay, an authentication mechanism, or a spam filter. It also names no plugin. The consequence is that the questions which decide whether you can run it safely, namely how users authenticate, what a session cookie looks like, and whether attachments get scanned, are answered somewhere other than here. For an evaluator this is the deciding detail: the top level document is a project description and a set of pointers, not an operations guide. Anything your decision hinges on, from certificate handling to credential storage, cannot be answered from it, and the search for those answers costs more than reading the install document up front.

Editorial conclusion

Roundcube Webmail fits teams that want mail reached at a URL through a browser IMAP client rather than an installed desktop program, and it fits badly as a document you evaluate from alone, because the top level file points to docs/INSTALL.md for anything operational. Before installing, decide which line you intend to run, since 1.7.5 and 1.6.20 both shipped on October 19, 2026, and pick a database from MariaDB, MySQL, PostgreSQL, or SQLite to match. If you plan to run a checkout of master rather than a tag, use a separate database, which is exactly what the ATTENTION block asks for. The repository is not archived and was last pushed on October 25, 2026, so both release lines are still moving.

Frequently asked questions

Official sources

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