One-click apps for LXC containers

The Apps page lists ready-made apps. Pick one, fill in a few settings, and NexoVirt creates a Debian container and installs the app inside it. You follow the install live, and the guest page shows how to reach the app afterwards. Apps are free in every edition.

Available apps

App	What you get	Minimum	Settings
Docker host	Docker Engine and the Compose plugin from the official Docker repository	1 vCPU, 1 GiB, 8 GB	none
Nextcloud	Nextcloud on Apache, PHP and MariaDB, port 80	2 vCPU, 2 GiB, 16 GB	admin username, admin password, domain (optional)
WordPress	WordPress on nginx, PHP-FPM and MariaDB, port 80	1 vCPU, 1 GiB, 10 GB	site title, admin username, admin email, admin password, domain (optional)
Uptime Kuma	Uptime Kuma monitoring on port 3001	1 vCPU, 1 GiB, 8 GB	none (you create the admin account on the first visit)

Use Search apps and the category buttons (All and one per category, each with a count) above the cards to narrow the list; the cards are grouped by category.

The catalog comes from NexoVirt and is updated without a panel update. The panel syncs it once a day; Sync catalog on the Apps page syncs it right away. When a sync fails, the message says why: the catalog server refused this license (“The catalog server refused this license (403).”), answered with an error, could not be reached, or the catalog signature is not valid.

Requirements

• An agent of version 0.26.0 or newer on the node the container runs on (the agent runs the install inside the container). On a cluster, every node with its own agent can host apps.
• The base template, Debian 12 Bookworm (standard), in the LXC template library (it comes with the OS catalog). If it is missing, the app card says so.
• The provisioning worker (provision:work, installed with the panel’s cron jobs).
• Internet access from the container: the install downloads packages and the app.

Deploying an app

1. Open Apps in the sidebar and click Deploy on an app.
2. Under Container, choose Where it runs: Automatic (recommended) picks the node with the most room whose agent can install apps, or pick a node and storage yourself. Set the Hostname, and raise Cores, RAM and Disk if you like (they never go below the app’s minimum).
3. Choose the Network: DHCP on vmbr0, or a static address from an IP zone.
4. Set a Root password for the container and/or paste SSH public keys.
5. Fill in the app’s settings (for example the admin password) and click Deploy.

The live page first creates the container (unprivileged; Docker hosts also get the nesting and keyctl features), then switches to Install app and shows the install output as it runs. Most apps are ready in a few minutes; Nextcloud can take up to half an hour on slow connections.

When it is done, the guest page shows App in the Details card and an App information tab with how to reach the app, see below.

Caution

The apps listen on plain HTTP. Put a reverse proxy with TLS in front of them before you expose them to the internet.

Making an app reachable from the internet

Some apps are meant to be reached from outside, for example a reverse proxy (ports 80 and 443) or a mail server (25, 465, 587, 143, 993, 4190). For these, the deploy form shows the switch Make reachable from the internet when you pick a Network that is an IPv4 zone behind NexoVirt NAT on its node (Network > NAT on the node page). The form lists exactly which port forwards it creates; the public port is the same as the container port.

• The forwards are added and NAT is applied on the node as soon as the container exists. If that does not work, the live page shows a warning and the install still continues; add the forwards on the NAT page then.
• The deploy is refused, and nothing is created, when one of the ports is already forwarded on that node (for example “Port 25/tcp is already forwarded to 10.10.10.5 on this node.”), when the network uses DHCP or is not inside the node’s NexoVirt NAT, when the node’s network is marked as managed outside NexoVirt, or when the node has its own NAT rules you have not agreed to keep next to NexoVirt’s.
• Deleting the guest removes the forwards it got this way and applies NAT again. Forwards you added yourself on the NAT page are not touched.
• App notes can use {public_ip}: the node’s public address (the NAT uplink bridge), so a mail app can show the DNS records with the real address.

App information

A container created from an app has an App information tab on its guest page (admins). It shows:

• The app name, its status and the catalog version it was installed from.
• A Reachable from the internet switch or badge (see below).
• A table of the app’s ports: Port, Used for, Private network (the container address and port) and From the internet (the public address and port, or Not forwarded).
• Getting started: the app’s notes, with the container address and the settings you chose filled in (never a password).
• Manage: the app’s actions.

Reachable from the internet after install

For an app with internet-facing ports, the Reachable from the internet switch in the card header adds or removes the port forwards later, with the same rules as at deploy time (see Making an app reachable from the internet). It asks for confirmation first: turning it on adds forwards on the node’s public IP and applies NAT, turning it off removes the app’s forwards and applies NAT again (forwards you added by hand stay). It needs the NAT permission and a confirmation of your identity. Without the switch the card shows a Reachable from the internet badge (ports already forwarded) or Private network only.

Manage actions

Under Manage, each app lists the actions the catalog offers for it. Every action opens a small dialog with the fields it needs; passwords are never shown or prefilled.

Action	What it does
Reset admin password	Sets a new password for the app’s admin account (apps with an admin login).
Change domain	Changes the address the app answers on and restarts it (Nextcloud, WordPress, Vaultwarden and other apps whose configuration holds a URL). The new value then shows in the getting started notes.
Update	Moves the app to the release the catalog now offers. The row shows “Installed 6.65.0, available 6.71.0” or “Up to date (6.71.0)”; the Update button only appears when an update exists.

An Update takes a snapshot of the container first. If something goes wrong, open the container’s Snapshots tab and roll back to the snapshot named nx-app-<release>-<time>. When the container’s storage cannot take snapshots, the update is refused unless you tick Update without a snapshot, which means a failed update cannot be rolled back.

An action runs like the install: on the live provisioning page, with its output as it runs. The password or other field values are removed from the job once it has started. Actions need:

• The container to be running (“Start the container first.”) and no other job running on it (An action is running on this container with a link to follow it).
• An agent of version 0.26.0 or newer on the node.
• A finished install; they are not offered for a safety copy or a failed-over copy.
• The hosts.manage permission and a confirmation of your identity.

A failed action leaves the log on the page and changes nothing in the panel. Run it again from App information; a password is never replayed.

When an install fails

The container is kept. The live page shows the error and the install output; the full log is in /var/log/nexovirt-app.log inside the container (and /var/log/nexovirt/app-<vmid>.log on the node). Fix the cause (for example the container’s network) and click Retry: the install runs again with the current catalog script. The scripts are safe to run more than once. To start over, delete the guest.

An install that runs longer than the app’s time limit is stopped and marked failed.

REST API

• GET /api/v1/apps lists the apps with their minimums, ports (with public for internet-facing ports) and settings.
• POST /api/v1/hosts/{id}/apps/{slug} deploys an app. Fields: node (auto or a node name), storage (required unless node=auto), vmid (optional), name, cores, memory_mb, disk_gb, ip_source (dhcp or zone:<id>), password and/or ssh_keys[], owner_id, and settings (an object with the app’s setting keys), and expose (true to forward the app’s public ports, see above). The answer carries job_id and vmid, plus forwards and warnings listing the port forwards an expose deploy creates; follow the install with GET /api/v1/hosts/{id}/jobs/{jobId} (the create job) and the guest’s provisioning state.

curl -X POST https://panel.example.com/api/v1/hosts/1/apps/wordpress \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"node":"auto","name":"blog","password":"a-long-root-password",
       "settings":{"site_title":"My blog","admin_user":"admin","admin_email":"[email protected]",
                   "admin_password":"a-long-admin-password"}}'

• GET /api/v1/hosts/{id}/guests/lxc/{vmid}/app reads the container’s app: status, the installed release and the catalog_release, update_available, busy, the reachability of its ports and the actions with their fields (never a secret). 404 when the container has no app.
• POST /api/v1/hosts/{id}/guests/lxc/{vmid}/app/actions/{key} runs an action (key from the list above, for example reset_password; the field keys are listed there too). Body: {"fields": {...}, "without_snapshot": false}. The answer carries the job_id; 409 while another job runs on the container, 422 for any other refusal.

curl -X POST https://panel.example.com/api/v1/hosts/1/guests/lxc/150/app/actions/reset_password \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"fields":{"admin_password":"a-long-new-password"}}'

Apps are for administrators (web and admin API tokens). Customers and resellers cannot deploy apps yet.

Security

• Only NexoVirt publishes apps. The catalog is signed with the same key that signs panel releases, and the panel checks the signature and every script’s checksum before using it; the agent checks the checksum again on the node.
• Your settings reach the script as environment variables from a file inside the container; they are never put on a command line. The file is deleted before the script starts. Passwords are not stored by the panel after a successful install.
• The script runs as root inside the (unprivileged) container, not on the node.