# Adminer: a full database client in one PHP file > Adminer ships as a single deployable file that speaks to MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL and Oracle. Here is what that buys you, where the single-file design stops helping, and how to get a first connection running. **vrana/adminer** — Database management in a single PHP file - Repository: https://github.com/vrana/adminer - Website: https://www.adminer.org/ - Stars: 7,915 · Forks: 1,185 - Language: PHP - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/vrana-adminer ## What problem a single-file database client solves Most database GUIs assume you have a desktop, a package manager, and permission to install things. Adminer's premise is the opposite: you already have PHP running because your application runs on PHP, so the database client can be one file you copy to that server. The README describes it as "a full-featured database management tool written in PHP" that "consists of a single file ready to deploy to the target server." That sentence is the whole product argument. The audience follows from it. Shared hosting where you cannot install binaries. Staging boxes you reach only over HTTP. A developer who wants to inspect a SQLite file or a PostgreSQL schema without opening a terminal. Adminer also ships a second entry point, Adminer Editor, which the README says "offers data manipulation for end-users." That is a different audience: people who should be able to edit rows but not alter the schema. Engine coverage is unusually wide for a tool this size. The README lists MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL and Oracle as supported, with plugins for Elasticsearch, OpenSearch, SimpleDB, MongoDB, Redis, Firebird, ClickHouse, IGDB and IMAP. The plugins are not the same thing as supported engines. They are separate, and the README points to a user-contributed plugin page rather than claiming they are all bundled. ## How the single-file deployment actually works The repository is a source tree, not the artifact most people deploy. The root holds adminer/, editor/, compile.php, lang.php, plugins/, designs/, conf/ and tests/. The README is explicit that the compiled file is the deliverable: requirements are PHP 5.3+ for the compiled file and PHP 7.4+ for the source codes. That gap matters. If you clone the repository and serve it directly, you are on the stricter requirement. compile.php is the mechanism that collapses the tree into one file. The README lists it plainly as "Create a single file version." Translations are handled separately by lang.php, and end-to-end coverage lives in tests/*.spec.js as Playwright specs. So the shipped single file is a build output assembled from PHP sources, language files and whatever plugins you choose to include. The two entry points are adminer/index.php for the development version of Adminer and editor/index.php for the development version of Adminer Editor, which the README notes "needs adminer/ next to it." There is also editor/example.php, described as an example customization, which is the starting point if Adminer Editor's default surface is too much or too little for the people using it. This is a build-then-deploy architecture rather than a framework you extend in place. If you want a plugin in your single file, you are deciding at compile time, not at runtime. ## Installing Adminer and making a first connection There is no package manager step in the README. Installation starts with getting the code, and the README gives one command for the Git route: if you downloaded from Git, run the submodule init, or composer install. The repository has a .gitmodules file at the top level, which is consistent with that instruction. ```bash git submodule update --init ``` After that, the README points at adminer/index.php as the development version you can run. Serve the repository with any PHP-capable web server and open that path. You should see the login form, where you supply the database server, credentials and the engine you are connecting to. For the single file most people actually deploy, the README names compile.php as the tool that creates it. ```bash php compile.php ``` The output is the one-file Adminer you copy to the target server. The README does not spell out the output filename or the exact flags compile.php accepts, so check the script itself before scripting this in a build pipeline. The README does not document a Docker image or a Dockerfile. Docker appears in the related searches, and third-party images exist, but nothing in the repository's own documentation describes one, so treat any container route as coming from outside this project. The same caution applies to a Laravel integration: the README does not describe one. If you want the end-user variant instead of the full tool, the README says editor/index.php runs the development version of Adminer Editor and needs adminer/ next to it. editor/example.php is the documented starting point for customizing it. ## Where the one-file model gets in the way A single file is easy to deploy and hard to govern. There is no dependency manifest to audit at the deployment target, because the dependencies were folded in at compile time. If a bundled plugin or translation has a problem, you do not patch it on the server. You rebuild. The PHP version split is a real constraint, not a footnote. PHP 5.3+ applies to the compiled file; the source codes need PHP 7.4+. Teams running an old PHP to keep a legacy application alive can use the compiled Adminer, but they cannot run the repository tree. Anyone who clones the repo onto a PHP 5.x host will hit that boundary, and the README gives no fallback. The plugin story is also looser than the engine list suggests. The README separates engines it supports from plugins, and it points to a user-contributed plugin page for the rest. That means plugin quality, maintenance and compatibility are not uniform, and the README makes no claim that they are. If your database is only reachable through a plugin, you are depending on code the project does not present as core. Finally, the README does not document rollback, migration between versions, or what changes between v6.0.1, v6.0.2 and v6.1.0. CHANGELOG.md exists at the top level, so the upgrade path is documented there rather than in the README. Read it before moving a production instance. ## Adminer compared with phpMyAdmin The comparison people keep making is Adminer versus phpMyAdmin, and the difference is structural rather than cosmetic. phpMyAdmin is a PHP application you install as a directory of many files, configured through its own setup process. Adminer is compiled down to one file and dropped on the server. Deployment, upgrade and removal all follow from that. The second difference is scope. phpMyAdmin is built around MySQL and MariaDB. Adminer's README lists MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL and Oracle in the same tool, with plugins extending further. If you only ever touch MySQL, that breadth buys you little and phpMyAdmin's MySQL-specific surface may be the better fit. If you routinely move between a PostgreSQL staging database and a SQLite file on a laptop, one client with one login form is the point. Adminer Editor is a third position neither of those occupies by default: a reduced interface for people who manipulate data but should not be changing schemas. That is a deliberate product split, and it is the reason editor/ exists as a separate entry point that needs adminer/ beside it. ## Maintenance, licensing and upgrade cost The project is not archived, and the last push was on 2026-09-21. Releases are frequent: v6.0.1 on 2026-08-14, v6.0.2 on 2026-09-07, and v6.1.0 on 2026-09-14. A cadence that tight cuts both ways. Security fixes arrive quickly, and so do version bumps you have to evaluate. Because deployment is a file copy, the upgrade itself is cheap; the cost is in reading CHANGELOG.md and re-running compile.php if you use plugins or customizations, since those are baked in at build time. The licence is the open question. The repository metadata reports NOASSERTION, which means the licence could not be classified automatically. There is a LICENSE file at the top level, so the terms exist, but this article will not guess at them. Read that file before you ship Adminer inside a product or expose it publicly, and if your organisation has a licence review process, route it through that rather than treating NOASSERTION as permissive by default. Nothing here is legal advice. ## Conclusion Adminer fits teams that want a database client they can drop next to the application on the same PHP host, and anyone who needs to reach several engines without installing a desktop tool. It is the wrong choice if you need the deeper schema-editing surface of phpMyAdmin for MySQL specifically, or if your host cannot run the required PHP version. Before committing, verify the PHP version your target satisfies (5.3+ for the compiled file, 7.4+ for the source tree), confirm the single-file build is what you actually deploy, and check whether the plugin you need is bundled or only user-contributed. The project's own release cadence is current: the last push was on 2026-09-21, with v6.1.0 tagged on 2026-09-14. ## FAQ ### What is Adminer used for? It is a full-featured database management tool written in PHP, used to manage MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL and Oracle databases. A second variant, Adminer Editor, offers data manipulation for end-users. ### How do I install Adminer? The README gives no package manager step. If you downloaded from Git, run the submodule init or composer install, then serve adminer/index.php for the development version, or run compile.php to create the single file version you deploy to the target server. ### Is Adminer better than phpMyAdmin? The README does not compare them. The structural difference is that Adminer compiles to a single file ready to deploy while supporting several engines in one tool, whereas phpMyAdmin is built around MySQL and MariaDB. Which is better depends on whether you need that multi-engine coverage. ### How do I use Adminer with SQLite? SQLite is listed among the supported databases in the README, so it is selected as the engine on the login form. The README does not document a separate SQLite-specific setup step. ### How do I use an Adminer plugin? Plugins are distributed with Adminer and many more are user-contributed on the Adminer Plugins page. Since deployment is a compiled single file, a plugin is included when you build with compile.php rather than enabled at runtime. ## Sources - [Issues](https://github.com/vrana/adminer/issues) - [Project website](https://www.adminer.org/) - [README](https://github.com/vrana/adminer/blob/main/README.md) - [Releases](https://github.com/vrana/adminer/releases) - [vrana/adminer on GitHub](https://github.com/vrana/adminer) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vrana-adminer