# The froxlor main branch says do not put me on a production server > froxlor is a hosting control panel for domains, mail, FTP and databases, and this repository is the next generation written as a Laravel application shell over a set of Composer packages. Its own README marks `main` as very early development, not for production, with security reports explicitly not accepted on that branch, while the stable 2.3 line lives on a separate branch. **froxlor/froxlor** — The server administration software for your needs - The official Froxlor development Git repository - Repository: https://github.com/froxlor/froxlor - Website: http://www.froxlor.org - Stars: 1,751 · Forks: 467 - Language: PHP - License: LGPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/froxlor-froxlor ## The branch you are reading is the wrong one for production The first thing the README does is stop you. A caution notice states that the `main` branch of `froxlor/froxlor` is at a very early stage of development, that it is incomplete, that it changes constantly, and that it is not meant to be used in production. It goes further: do not open security reports, advisories or issues about security topics for this branch, because they will not be accepted or processed. Known gaps are expected at this stage and are being worked on. A second notice points at the stable version. The current stable release, froxlor 2.3, lives in the `v2.3` branch of the same repository, and the instruction is to use that branch or one of its releases if you want to run froxlor on a real server. That explains a fact that would otherwise look contradictory. The release history in this repository lists 2.3.15 on 2026-10-04, 2.3.14 on 2026-09-15 and 2.3.13 on 2026-08-28, three patch releases in six weeks, on a branch whose README says it is unusable. The releases come from `v2.3`; the tag list is just showing the whole repository. The last push was on 2026-10-13, so both lines are being worked on. Documentation for the stable version is at docs.froxlor.org, separate from the repository. Read the branch name before anything else in this project. ## This repository is a shell, the functionality is five Composer packages It is described as the application shell: a Laravel application that wires the froxlor packages together, and the actual functionality lives in Composer packages pulled in through `composer.json`. The dependency structure is drawn in the README as a tree: ```text froxlor/froxlor Laravel application (this repository) froxlor/framework Metapackage, requires the packages below ├── froxlor/core Tenants, users, environments, nodes, roles/permissions, │ plans/resources, settings, audit logging, shared services ├── froxlor/packages Package management └── froxlor/ui UI components (tables, forms, widgets, ...) ``` Feature modules for domains, mail, FTP, databases and web are separate packages that build on `froxlor/core`. The related repository table adds `froxlor/container`, which holds the Docker image and the development setup. Two things follow from this shape. The first is that reading this repository tells you about the wiring, not about the behaviour, so a question like how FTP accounts are created has its answer in a different repository. The second is that the boundaries are usable: a project that wants `froxlor/core` for tenants and nodes without the whole panel can depend on it directly. The skeleton is the Laravel application skeleton, and the files taken from it keep the MIT licence, tracked through a `REUSE.toml` and a `LICENSES/` directory at the root. ## Tenant, User, Environment, Node, Plan, Resource The concepts are given in a nutshell and they are the vocabulary you need before reading any other part of the code. A Tenant is a customer or managed hosting entity. There is one root tenant and all others are its descendants, and the tenant is the primary authorization boundary. That is the design decision with the most weight: every other object hangs off the tree, and access control is a question about which subtree you are in. A User is a person logging into froxlor, assigned to tenants and/or environments with individual roles and plans. A User is therefore not the same thing as a tenant holder, and a login can exist at more than one level. An Environment is an execution or deployment context, the README's example being a jail on a node, in which resources such as domains, mailboxes or FTP accounts live. A Node is a machine, local or remote, that hosts environments, and communication with a node happens through adapters. That adapters boundary is the important one operationally. Whatever the node is running, froxlor does not talk to it directly; it talks through an adapter, which is where you would implement support for infrastructure the project does not know about. Plan and Resource are a pair. A plan is a reusable set of resource limits, and resources describe what can be limited, which is how one customer tier is defined once and applied to many tenants. The flow that connects them is stated as a chain: Controller, then Service, then Domain Action, then Job or Event, then Adapter, then Infrastructure. ## Configuration is a Laravel env file with sensible defaults for a container The repository is a Laravel application, so configuration is the Laravel `.env` file, and `.env.example` at the root is the template. The defaults reveal the intended deployment. Database is MariaDB, with `DB_CONNECTION=mariadb`, host `db` and port 3306, database and user both `froxlor`, and an empty password. The host name `db` is a Docker network name, so the shipped defaults assume a container setup. State handling is database backed across the board: `SESSION_DRIVER=database` with a 120 minute lifetime and `SESSION_ENCRYPT=false`, `QUEUE_CONNECTION=database`, `CACHE_STORE=database`, `BROADCAST_CONNECTION=log` and `FILESYSTEM_DISK=local`. Redis and memcached entries exist with `REDIS_CLIENT=phpredis` on port 6379 and `MEMCACHED_HOST=127.0.0.1`, but they are not what the defaults select. Mail defaults to the log mailer writing to `MAIL_MAILER=log`, which in a development environment means nothing leaves the machine. AWS S3 keys are present and empty with `AWS_DEFAULT_REGION=us-east-1` and `AWS_USE_PATH_STYLE_ENDPOINT=false`, for the cases where remote storage is wanted. Two defaults are worth noticing as security posture. `APP_ENV=production` and `APP_DEBUG=false` in the shipped example, which means debug output is off unless you turn it on. And `BCRYPT_ROUNDS=12`, which is the work factor for password hashing. ## LGPL-3.0-or-later with an extension package exception The licence needs reading carefully, because the next generation is not a plain LGPL. The README gives the SPDX identifier as `LGPL-3.0-or-later WITH LicenseRef-froxlor-Extension-Package-Exception`, meaning GNU Lesser General Public License version 3 or, at your option, any later version, together with the froxlor Extension Package Exception. Four licence files sit at the root: `COPYING.LESSER` with the LGPL version 3, `COPYING` with the GPL version 3 incorporated by the LGPL, `LICENSE-EXCEPTION` with the froxlor exception, and `AUTHORS` naming the copyright holders. The exception matters and its name is the clue. An extension package exception in an LGPL project is the mechanism that lets you publish additional modules under different terms while keeping the LGPL terms on the code they link to. Whether it does what you need depends on the text in `LICENSE-EXCEPTION`, not on the identifier. Separately, the files taken from the Laravel skeleton keep the MIT licence, and `REUSE.toml` plus `LICENSES/` track which is which. A `REUSE.toml` in a project of this size is a sign the licensing is handled deliberately rather than assumed. The site is froxlor.org and the repository homepage is www.froxlor.org. ## Where the stable branch, or another panel, fits instead If the goal is a working hosting panel today, the answer is not this branch. froxlor 2.3 on the `v2.3` branch is described as the stable release, with its own documentation site, and it is the only one of the two the project asks you to put in front of customers. What this repository is genuinely good for is contributing, and for a development environment without setting anything up: the README names the froxlor container as the easiest way to try froxlor or to set up a development environment, pointing at its `README.md` and `DEVELOPERS.md`. The tooling in the repository is conventional Laravel and PHP: `artisan` at the root, `bootstrap/`, `database/`, `public/`, `storage/` and `tests/`, a `phpunit.xml` for tests, a `pint.json` for code style and an `.htaccess` at the root for the public directory. ## Conclusion Adopt this repository if you want to contribute to froxlor's next generation or to run a development environment from the container image, because the architecture is a clean separation between an application shell and packages you can depend on individually. Do not deploy `main` on a server that serves customers: the README states it is incomplete, changes constantly, is not meant for production, and that security reports on that branch are not accepted or processed. Verify first that you are on the `v2.3` branch or one of its releases if the goal is a working panel. ## FAQ ### Is the froxlor main branch safe for production? No. The README marks `main` as very early development, incomplete, changing constantly and not meant to be used in production, and states that security reports on that branch are not accepted or processed. Use the `v2.3` branch or one of its releases instead. ### Where does the froxlor source code actually live? Not in this repository. This one is the Laravel application shell; the functionality lives in the `froxlor/core`, `froxlor/packages` and `froxlor/ui` Composer packages, required through the `froxlor/framework` metapackage. ### What is a tenant in froxlor? A customer or managed hosting entity. There is one root tenant and all others are its descendants, and the tenant is the primary authorization boundary for the whole system. ### How does froxlor talk to a server? Through adapters. A Node is a machine that hosts environments, and communication with it happens through adapters. Infrastructure changes follow the flow Controller, Service, Domain Action, Job or Event, Adapter, Infrastructure. ### What licence does the next generation of froxlor use? LGPL-3.0-or-later WITH LicenseRef-froxlor-Extension-Package-Exception. The root holds COPYING.LESSER, COPYING, LICENSE-EXCEPTION and AUTHORS, and the Laravel skeleton files keep MIT via REUSE.toml. ## Sources - [froxlor/froxlor on GitHub](https://github.com/froxlor/froxlor) - [License: LGPL-3.0](https://github.com/froxlor/froxlor/blob/main/LICENSE) - [Project website](http://www.froxlor.org) - [README](https://github.com/froxlor/froxlor/blob/main/README.md) - [Releases](https://github.com/froxlor/froxlor/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/froxlor-froxlor