The Admidio command-line interface (CLI) provides a scriptable administrative interface to Admidio directly from a shell.
The executable is located in the top-level Admidio directory and is called admidio. It is executed from a shell in the Admidio installation directory:
www-data@server.example.com:~/html$ ./admidio status Organization: TEST Filesystem: 5.1.0 Beta 1 Database: 5.1.0-Beta.1 Update step: 620 Status: OK
The CLI uses the same Admidio entities, services, permissions, organization context and database as the web application. It is therefore suitable both for interactive administration and for automation without duplicating Admidio business logic in external scripts.
Typical use cases include:
For the exact list of commands, arguments and command-specific options see the CLI command reference.
Developers who want to add CLI commands to an Admidio module should see Adding CLI commands to Admidio modules.
Most commands operate on an existing Admidio installation. For those commands you need:
adm_my_files;The CLI does not start a browser session and does not require a web server request.
A small set of commands is deliberately available before Admidio has been installed. This allows a new installation to be inspected and created entirely from the command line:
./admidio help ./admidio list ./admidio completion ./admidio cli:selfcheck ./admidio install:check ... ./admidio install:run ...
The examples on this page assume that the current directory is the Admidio installation directory.
On Linux and other Unix-like systems the script can be made executable:
chmod +x admidio ./admidio version
It can also always be started explicitly through PHP:
php ./admidio version
On Windows, use the PHP executable:
php .\admidio version
The command can also be called using an absolute path. This is recommended for cron jobs and other automation:
/usr/bin/php /var/www/admidio/admidio status
The general syntax is:
admidio [global-options] COMMAND [arguments] [options]
For example:
./admidio user:show john.doe --as=administrator --format=json
A command consists either of a simple name such as:
version status help list completion
or a namespace and task:
user:add group:adduser inventory:export sso:list
Global options can be placed before or after the command. Command-specific options must be placed after the command because the CLI cannot know them before it has identified the command.
Both of these forms are valid:
./admidio --organization=club user:list --as=administrator --format=json ./admidio user:list --organization=club --as=administrator --format=json
Long options that take a value accept both –name=value and –name value. The = form is usually clearer in scripts.
The separator – stops option parsing. This is useful when a positional argument itself begins with a hyphen.
To display the general usage, global options and exit codes:
./admidio help
The following are equivalent shortcuts:
./admidio --help ./admidio -h
To list all registered commands:
./admidio list
Commands of one namespace can be listed separately:
./admidio list user ./admidio list inventory ./admidio list sso
The list also shows whether a command is an alias and whether it is currently available.
To show the documentation for a specific command:
./admidio help group:adduser
You can also use:
./admidio group:adduser --help ./admidio group:adduser -h
To inspect the namespaces and tasks represented in the registry:
./admidio module:list ./admidio module:tasks ./admidio module:tasks inventory
The complete generated command documentation is available with:
./admidio help --all
It can be rendered directly as Markdown, DokuWiki or JSON:
./admidio help --all --format=md ./admidio help --all --format=dokuwiki ./admidio help --all --format=json
The CLI command reference is generated from the same registry metadata, for example:
./admidio help --all --format=dokuwiki --output=cli-commands.txt
Therefore the generated page should correspond to the installed Admidio version, including commands supplied by modules.
Current limitation: the generated command metadata and therefore the generated CLI command reference are currently available in English only. This is a known CLI limitation. Translated overview/developer pages should link to the English command reference until CLI help localization is implemented.
The following options control the CLI itself.
| Option | Description |
|---|---|
–host=HOST | Selects the host used while loading an installation whose adm_my_files/config.php contains host-dependent configuration. |
–organization=ORG | Selects the Admidio organization by its short name. |
–as=USER | Selects the Admidio user whose permissions and audit identity are used for the command. |
–format=FORMAT | Selects an output format where supported. The formats supported by a particular command are listed in its help. |
–output=FILE | Writes command output to a file where supported. |
–quiet / -q | Suppresses human-readable success confirmations. Requested data, JSON results and errors are still emitted. |
–no-interaction | Prevents the command from asking interactive questions. |
–yes / -y | Confirms destructive or otherwise explicitly confirmed operations without asking interactively. |
–help / -h | Displays help for the selected command. |
Not every global output option has a meaningful effect for every command. Always use admidio help COMMAND when scripting a specific operation.
Many commands require an acting Admidio user:
--as=USER
USER can be a user UUID, numeric user ID or unique login name.
For example:
./admidio user:list --as=administrator
Important: –as is not a password login.
The CLI is a local administrative interface. A person or service account that can execute the CLI and read the Admidio configuration/database can select an Admidio account as the acting identity. Operating-system permissions around the Admidio installation are therefore an important security boundary.
The selected Admidio account must nevertheless be usable. An acting user must:
Admidio then applies the normal authorization model to the command. The exact check depends on the operation:
The command-specific help states additional declared requirements where applicable.
The acting user also becomes the current Admidio user for normal entity and changelog processing. CLI changes are marked with an origin such as:
CLI: group:adduser
Do not use an administrator identity unnecessarily. For automated tasks, use an activated Admidio account with only the permissions required by the task.
For installations with several organizations, use:
./admidio --organization=club-a user:list --as=administrator
The value is the organization's Admidio short name.
The option changes the organization context before the CLI initializes organization-dependent Admidio objects and preferences.
The acting user selected with –as must be an active member of the selected organization.
Some installations use $_SERVER['HTTP_HOST'] in adm_my_files/config.php to select different database or environment settings.
There is no HTTP request when the CLI starts, so the desired host can be supplied explicitly:
./admidio --host=members.example.org status
The same value can be supplied through the environment variable ADMIDIO_HOST:
export ADMIDIO_HOST=members.example.org ./admidio status
The value must be a host name, optionally including a port, for example:
members.example.org members.example.org:8080
Do not include a URL scheme or path.
This option selects the configuration environment. It is not the hostname of a phpMyAdmin installation or another database administration interface.
Different commands support different output formats. Use command-specific help to see the exact formats accepted by a command:
./admidio help sso:list
Formats used by CLI commands include:
| Format | Intended use |
|---|---|
text | Simple human-readable output. |
table | Tabular terminal output. Best for compact lists. |
record | One field per line, including nested values. Best for wide records and complete entities. |
json | Structured output for scripts and external applications. |
csv | Tabular data for spreadsheets and other tools. |
md | Markdown output where supported. |
dokuwiki | Native DokuWiki markup where supported. |
Not every command supports every format.
A normal table is useful for short lists:
./admidio sso:list --format=table --as=administrator
For objects with many fields, the record format is easier to read:
./admidio sso:list --format=record --as=administrator
Example:
type: saml id: 2 uuid: 2b8618d0-... client_id: intranet name: Intranet SAML enabled: yes type: oidc id: 3 uuid: 90c9777a-... client_id: wiki name: Wiki enabled: yes
For scripts, use JSON wherever possible:
./admidio user:list --format=json --as=administrator
If –format=json is present and the CLI fails, the error is also written as structured JSON to standard error. A failure contains the error message, exception type and exit code. This makes it possible for automation to handle errors without parsing human-readable text.
Mutating commands that only have a success confirmation also return a JSON object when –format=json is requested.
Commands using normal CLI output can write it directly to a file:
./admidio config:list --format=json --output=preferences.json --as=administrator
Commands that generate an export or backup also use –output. Depending on the command, the value can be an explicit filename or a destination directory for the command's natural filename.
For example:
./admidio database:backup \ --output=/srv/backups/admidio.sql.gz \ --as=administrator
Always check:
./admidio help COMMAND
before using output paths in an automated script.
Scripts should always inspect the process exit code.
| Code | Meaning |
|---|---|
0 | The command finished successfully. |
1 | Internal CLI error, for example a database failure or PHP error. |
2 | Usage error: unknown command, missing argument, invalid option or invalid value. |
3 | The command ran, but the state it reports is not OK. Used for checks such as status, htaccess:status and a failing cli:selfcheck. |
4 | The command ran successfully and a newer Admidio release is available. Used by update:check. |
5 | Admidio rejected the operation, for example because of missing rights or domain validation. |
6 | The operation was valid and permitted but could not be completed. |
Do not treat every non-zero code as the same type of failure. For example, exit code 4 from update:check is a successful check whose result is “an update is available”.
A new Admidio installation can be checked and created without opening the browser installer.
First validate the database connection, installation values and prerequisites:
./admidio install:check [options]
Then run the installation:
./admidio install:run [options] --yes
If values are missing and interaction is allowed, the CLI asks for them. With –no-interaction, every required value must be provided as an option.
A typical non-interactive invocation provides:
For example:
{ printf '%s\n' "$ADMIDIO_DB_PASSWORD" printf '%s\n' "$ADMIDIO_ADMIN_PASSWORD" } | ./admidio install:run \ --db-type=mariadb \ --db-host=localhost \ --db-name=admidio \ --db-user=admidio \ --db-password-stdin \ --root-url=https://www.example.org/admidio \ --timezone=Europe/Berlin \ --organization-shortname=EXAMPLE \ --organization-name="Example Organization" \ --organization-email=info@example.org \ --admin-login=admin \ --admin-first-name=Anna \ --admin-last-name=Admin \ --admin-email=anna@example.org \ --admin-password-stdin \ --no-interaction \ --yes
When both database and administrator passwords are read from stdin, the database password is the first line and the administrator password is the second line.
Run install:check with the same values first when provisioning a production installation.
The generated command reference is the authoritative list, but the CLI currently covers the following main areas:
adm_my_files protection and maintenance;Use:
./admidio list NAMESPACE
to see the exact commands in one area.
./admidio version ./admidio status
status compares the Admidio source with the database core version and reports the current organization and database update state.
It returns exit code 3 if the state is not OK.
Example:
./admidio status --format=json > /tmp/admidio-status.json code=$? if [ "$code" -ne 0 ]; then echo "Admidio status requires attention (exit $code)." >&2 fi
Capture the exit code immediately after the command before running another shell command.
./admidio update:check --as=administrator
For automation:
./admidio update:check --format=json --as=administrator
Exit code 4 means that a newer release is available.
The CLI can validate its registry, generated help and internal CLI source consistency:
./admidio cli:selfcheck
For CI or other automation:
./admidio cli:selfcheck --format=json
A problem is reported with exit code 3.
This self-check validates the CLI infrastructure. It does not replace behavioral tests of the underlying Admidio domain operations.
Bash and Zsh completion scripts can be generated from the command registry:
./admidio completion bash > /etc/bash_completion.d/admidio
or:
./admidio completion zsh > "${fpath[1]}/_admidio"
Commands that are registered as unavailable are omitted from completion.
List all preferences:
./admidio config:list --as=administrator
Search preference names:
./admidio config:list --filter=events --as=administrator
Read one value:
./admidio config:get system_language --as=administrator
Change one value:
./admidio config:set events_module_enabled 1 --as=administrator
Before changing preferences through scripts, verify the setting name and accepted value in the normal Admidio configuration and command help.
./admidio user:list --as=administrator ./admidio user:show john.doe --as=administrator
Use the record format for a readable full object where that format is supported:
./admidio user:show john.doe --format=record --as=administrator
Use JSON for automation:
./admidio user:show john.doe --memberships --relations --format=json --as=administrator
Admidio profile fields are configurable. User data is therefore supplied using the internal profile-field names:
./admidio user:add \ --login=john.doe \ --field=FIRST_NAME=John \ --field=LAST_NAME=Doe \ --field=EMAIL=john@example.org \ --as=administrator
The configured profile fields can be inspected with:
./admidio profile:fields --as=administrator
A user can immediately be assigned to groups:
./admidio user:add \ --login=john.doe \ --field=FIRST_NAME=John \ --field=LAST_NAME=Doe \ --group=Members \ --as=administrator
If a command accepts a password or another secret, prefer its *-stdin option over putting the secret in shell history.
Assign an existing user:
./admidio group:adduser Members john.doe --as=administrator
Assign the user for a defined period:
./admidio group:adduser Board john.doe \ --start=2026-09-01 \ --end=2027-08-31 \ --leader=yes \ --as=administrator
End the current membership:
./admidio group:deluser Board john.doe --as=administrator
Update an existing membership:
./admidio group:updateuser Board john.doe \ --leader=no \ --as=administrator
Normal membership operations preserve Admidio's membership history.
Permanent deletion of a membership-history row is a separate operation:
./admidio group:deletemembership MEMBERSHIP_UUID --as=administrator
It requires confirmation and should only be used deliberately.
Create a database backup:
./admidio database:backup --as=administrator
Write it to a specific destination:
./admidio database:backup \ --output=/srv/backups/admidio.sql.gz \ --as=administrator
Database dumps contain the complete installation data and are protected as private files where the operating system permits it.
Take a backup before larger scripted changes or migrations.
Before importing, preview the resolved mapping without writing data:
./admidio inventory:import-check ./inventory.xlsx \ --format=json \ --as=administrator
Import an inventory file:
./admidio inventory:import ./inventory.xlsx --as=administrator
The importer supports explicit mapping when source columns do not correspond to the configured Admidio inventory fields:
./admidio inventory:import ./inventory.csv \ --input-format=CSV \ --separator=semicolon \ --map=ITEMNAME=1 \ --map=CATEGORY=2 \ --map=SERIAL_NUMBER=3 \ --as=administrator
Export inventory data:
./admidio inventory:export \ --format=xlsx \ --output=inventory.xlsx \ --as=administrator
Always use admidio help inventory:import or admidio help inventory:export for the exact file formats and options supported by your installed Admidio version.
Events and rooms can be administered through their CLI command families.
For example, creating an event:
./admidio event:add \ --headline="Annual meeting" \ --calendar=General \ --from="2026-09-14T18:00" \ --to="2026-09-14T20:00" \ --location="Club house" \ --as=administrator
Use:
./admidio list event ./admidio list room
and admidio help COMMAND for the exact event and room operations and options of the installed version.
List all SSO clients:
./admidio sso:list --format=record --as=administrator
Show only SAML clients:
./admidio sso:list --type=saml --format=record --as=administrator
Inspect one client:
./admidio sso:show CLIENT_UUID --as=administrator
SSO keys, SAML metadata, OIDC discovery information and token cleanup can also be administered through the corresponding sso:* commands.
See the command reference for the full list.
The maintenance switch can be queried even when the database is unavailable:
./admidio maintenance:mode ./admidio maintenance:mode status
Enable it interactively:
./admidio maintenance:mode enable \ --message="Maintenance in progress" \ --retry-after=300
For deliberate non-interactive use:
./admidio maintenance:mode enable \ --message="Maintenance in progress" \ --retry-after=300 \ --no-interaction \ --yes
Disable maintenance mode:
./admidio maintenance:mode disable
Maintenance mode has an owner identifier so independent maintenance operations do not silently take over each other's state. Use command help before using –owner or –force in automation.
The CLI is designed to be scriptable.
For reliable automation:
–no-interaction;–yes only when a destructive or confirmed action is deliberately accepted by the script;–format=json for machine-readable output;*-stdin options for passwords and secrets when available;#!/bin/sh ADMIDIO=/var/www/admidio/admidio ACTOR=automation-admin "$ADMIDIO" status --format=json --output=/tmp/admidio-status.json status_code=$? if [ "$status_code" -ne 0 ]; then echo "Admidio installation requires attention (exit $status_code)." >&2 exit "$status_code" fi "$ADMIDIO" group:members Members \ --format=json \ --as="$ACTOR" \ --no-interaction \ --output=/tmp/admidio-members.json
$Admidio = "C:\inetpub\wwwroot\admidio\admidio" $statusJson = php $Admidio status --format=json $statusCode = $LASTEXITCODE if ($statusCode -ne 0) { Write-Error "Admidio installation requires attention (exit $statusCode)." exit $statusCode } $status = $statusJson | ConvertFrom-Json $users = php $Admidio user:list ` --format=json ` --as=automation-admin | ConvertFrom-Json $users | ForEach-Object { Write-Host $_.login }
For cron jobs, call the CLI by absolute path and disable interaction.
Example:
15 2 * * * /usr/bin/php /var/www/admidio/admidio database:backup --output=/srv/backups/admidio.sql.gz --as=backup-admin --no-interaction
Make sure that the operating-system user running the scheduled task has access to:
adm_my_files;
Also make sure that the Admidio account used with –as remains activated and an active member of the selected organization.
The CLI can be used as an administrative boundary between another application or migration script and Admidio.
Instead of writing directly to the Admidio database, an integration can invoke the relevant Admidio command.
For example, an external provisioning script can:
user:add;user:update;group:adduser;group:deluser;user:show –format=json.This approach has an important advantage over direct SQL: the command uses Admidio's normal entities, services, permissions, changelog and related update logic.
A typical migration from another membership system could proceed as follows:
profile:fields;user:add or user:update for each person;group:adduser to recreate memberships and their start/end dates;user:list, group:members and JSON exports.For large migrations, first test the complete process against a copy of the production installation.
Many commands allow an object to be referenced by more than one identifier, for example:
Interactive administration can conveniently use names:
./admidio group:adduser Board john.doe --as=administrator
For long-lived integrations, prefer UUIDs where the command accepts them.
Names may be changed and can sometimes be ambiguous. When a selector is ambiguous, the CLI fails rather than silently selecting one object.
Commands that require confirmation ask interactively by default.
For example:
./admidio group:delete OldGroup --as=administrator
For a deliberately automated operation:
./admidio group:delete OldGroup \ --as=administrator \ --no-interaction \ --yes
If a confirmation would be required and –no-interaction is present without –yes, the command fails instead of silently continuing.
Do not add –yes indiscriminately to every automated command. It should show that the script intentionally accepts that operation.
A command can be present in the registry but marked as unavailable when the corresponding web functionality does not yet have a reusable headless operation.
admidio list shows this state, and admidio help COMMAND includes an availability notice.
Shell completion omits commands that are marked unavailable.
Do not work around an unavailable command by manipulating the Admidio database directly. Use the corresponding supported web functionality or wait until the required reusable core operation is available.
The CLI loads adm_my_files/config.php from the Admidio installation.
If that configuration selects an environment based on HTTP_HOST, specify the expected host:
./admidio --host=members.example.org status
or set:
ADMIDIO_HOST=members.example.org
The selected command needs an acting Admidio identity.
Supply an activated user that is an active member of the current organization:
./admidio COMMAND --as=administrator
Remember that –as selects an identity; it does not perform password authentication.
An account used with –as must be activated and currently belong to the selected organization.
Activate/assign the account using normal Admidio administration before using it as an automation actor.
The CLI does not bypass Admidio permissions.
Check:
Use the UUID shown by the corresponding list or show command.
Not every format is valid for every command.
Use:
./admidio help COMMAND
to see the exact allowed values.
Read the availability explanation in:
./admidio help COMMAND
The registry intentionally exposes the reason rather than silently offering an incomplete headless implementation.
Module commands are loaded from:
modules/<module>/cli.php
If loading a module's CLI registration fails, the CLI writes a warning to standard error and continues loading the remaining commands. Inspect the warning and then run:
./admidio module:tasks
to see what was registered successfully.
The CLI should be treated as an administrative server interface.
adm_my_files with appropriate filesystem permissions.–as is impersonation, not authentication.The complete command reference is generated directly from the installed CLI:
./admidio help --all --format=dokuwiki
To generate a file suitable for the DokuWiki page:
./admidio help --all --format=dokuwiki --output=cli-commands.txt
Because that page is generated directly from the command registry, it should be considered the authoritative description of command arguments, options, aliases, declared rights and availability for a particular Admidio version.
The generated command reference is currently English-only because CLI help metadata is not yet localized.