The Impreza catalog brings application deployment and ongoing operations into My Apps. Choose a supported app and a server with the Impreza Agent online, configure its required settings and follow the deployment status. Installation time depends on the app, image downloads and available resources.
What you get
- A curated catalog of ready-to-run apps for websites, files, automation and other workloads
- Automatic HTTPS for eligible web apps through Let’s Encrypt
- An optional Tor mirror for most web apps, published in the same install
- A custom domain or a free subdomain on imprezaapps.com for eligible web apps
What is in the catalog
- Security and privacy: Vaultwarden (passwords), SearXNG (private search), PrivateBin (encrypted pastes)
- Productivity and files: Nextcloud, Memos and Stirling-PDF for merging, compressing and running OCR on PDFs on your server
- Communication: Matrix (Synapse), Mattermost, Evolution API
- Automation: n8n, Activepieces
- AI: Ollama, Open WebUI, OpenClaw
- Developer tools: Gitea, Uptime Kuma
- Media: Jellyfin, PhotoPrism
- Sites and shops: WordPress, PrestaShop
- Databases: PostgreSQL, MySQL, MariaDB, MongoDB, Redis
- Remote access: RustDesk
MinIO is no longer available for new catalog installations. Existing deployments remain in place; see existing MinIO storage and recovery. The separate Impreza S3 app backup service remains available for supported app backups.
Install it
Browse the catalog
Open the catalog in your clientarea, or ask your AI assistant to list it. Each entry states what it needs: CPU cores, memory and disk.
Check the app fits the server
Compare the catalog requirements with the available CPU, memory and disk on your VPS. Leave room for data growth and recovery operations. Available resources are a current reading, not a reservation. A server running a traditional hosting panel follows a different workflow from the agent app catalog.
Choose a hostname
For an eligible web app, choose a hostname you control or take a free imprezaapps.com subdomain. A custom hostname needs DNS pointing to this server or an accepted account-bound TXT ownership proof, such as when using your own proxy/CDN. Follow the custom-hostname checklist before installing. After that check, configure and verify HTTPS for the web route separately. Enable a .onion mirror only when the selected app offers it: new PrestaShop installations do not support onion. Databases and RustDesk use their own access and transport settings instead.
Install and save the credentials
Review the settings required by the selected app, confirm installation and follow its status. As the account owner, open My Apps → Login details for platform-managed credentials where available, and store them privately. A password you create inside the app’s own setup wizard is separate. Complete first access and verify sign-in before sharing the address.
Finish first-time setup for the app you chose
A running container is the beginning of first access, not proof that an owner account exists. The catalog handles each app differently:
| App | What to do on a fresh installation |
|---|---|
| WordPress | If you omit the admin password or leave it blank, the catalog generates one and uses it to complete installation. After a successful install, use the credentials in My Apps. |
| Gitea | Without an admin password, finish the initial setup and create the admin immediately. Supplying a password selects automated setup; verify the result and registration settings. |
| n8n | Without an admin password, create the owner account immediately in the app. With a supplied password, the lifecycle attempts owner setup; verify sign-in rather than assuming it succeeded. |
| Nextcloud | Without admin credentials, complete the browser installer promptly. Supplying the admin credentials selects first-boot installation. |
| Vaultwarden | Create your own account; the platform does not generate its password. New-account registration initially opens for a configured window, 24 hours by default. Closure is checked periodically and needs a successful app update; verify it has closed before sharing the address. |
An unclaimed setup screen may let someone else create the first account. Other apps have their own onboarding rules. Read first launch: setup and login, then follow private credential entry when an existing app needs a supported secret runtime variable.
Configure app email separately
A free imprezaapps.com hostname is a web address, not an email service. The managed domain has mail-rejection DNS policies. If an app uses a default such as admin@<app>.imprezaapps.com or wordpress@<app>.imprezaapps.com, replace the administrative/contact address with one you control before relying on notifications or password recovery. Configure the app’s SMTP service and a sender on a domain you control; a working HTTPS site does not establish working email.
This applies when configuring apps such as WordPress, PrestaShop, Gitea or n8n. Changing the website hostname does not automatically change the app’s administrative email. See email on the platform domain for the policy.
Deploy from a visual panel in chat
In a compatible MCP Apps client, ask your assistant to list the available apps. The hosted connector and local impreza-mcp 0.55.1 can open a deploy wizard: choose an app, select an eligible server with its Agent online, and review the supported domain and Tor-mirror options before starting.
The wizard offers the options declared by the selected app. A database does not acquire a web route just because the panel has domain controls for web apps. Follow deployment progress and read the final result; container health and the deployment operation are separate states. If the client cannot display the wizard, use My Apps or the supported text workflow.
Confirm the public address after deployment
Read the deployment operation and its route result first. The current platform also verifies eligible public HTTPS addresses with a certificate check and limited retries. Diagnostics distinguish verified, failed and not checked TLS results; a pending or missing check is not a successful verification. Read the warning and check the installed app and route before retrying instead of installing another copy blindly.
The public TLS check applies only to an eligible HTTPS hostname whose DNS points to that deployment’s server; it does not check an onion route or follow arbitrary redirects. It is not continuous monitoring and does not verify every application function. A newly returned .onion address can take several minutes to answer; inspect the Tor publishing steps separately. Keep the server on a supported version through an explicit Agent update.
The database entries listen on raw ports such as 5432, 3306, 27017 and 6379, and those are scanned continuously across the whole internet. Keep database ports private even when transport encryption is enabled. For an app that publishes non-HTTP ports, Inbound access lets you allow selected IPv4/IPv6 source ranges per port. Ports start open; confirm your rules and wait for enforced. Filtering does not replace TLS or database authentication. These entries do not use the web-app HTTPS certificate or Tor mirror. Check the selected database engine’s own transport settings. New Redis installs require TLS by default, while existing installs keep their previous setting; when Redis TLS is disabled, its password travels in cleartext on that connection. See offshore database hosting for connection and recovery limits. RustDesk also follows a separate access flow.
On a compatible server, new web deployments start with Impreza Shield’s standard profile, which observes requests without blocking them. In the app’s Shield card you can review aggregate counters and choose hardened or max; WAF blocking needs a separate confirmation after you check for false positives. Existing deployments do not switch profiles automatically. See the Shield guide for supported agents and limits.
For a compatible web app, choose a Tor v3 mirror or onion-only access where offered. Compatibility depends on the app’s redirects, assets and sign-in behavior, not just the existence of an address. PrestaShop is excluded from new onion deployments; database and RustDesk entries use separate access settings. See how to publish a Tor .onion site.
You choose when to update and what to authorize. Use the app inspection and maintenance tools to investigate the app, and schedule supported recurring tasks when needed. Back up important data and test recovery before depending on an app in production.
Check connections to services on the server
If the app connects to a database, cache or other service running directly on the host, check the Agent version and firewall policy. Agent 0.6.25 lets the host firewall decide first and preserves access to published application ports. Older agents 0.6.21–0.6.24 blocked new container-to-host connections before the host’s own allow rules. Update those servers explicitly and follow container-to-host connection guidance; keep database ports private rather than opening them broadly.
Start with writable app data
With Agent 0.6.32, the Agent creates bind folders under the app’s ./data before applying its configured data owner, and refuses symbolic links along that path. This helps an image running as a non-root user write its state on the first start. It does not grant permissions to arbitrary external mounts. Update an existing Agent before relying on the new behavior.
Protect the app after installation
Use the app backup and restore guide for supported data stored in the Impreza S3 service associated with your account. Check that storage is available, inspect the app’s backup schedule and wait for a completed result. A requested or running backup is not yet a recovery point.
These backups cover the application data included by the deployment’s backup job. They are different from a whole-VPS backup: see how to manage your VPS from chat. A custom Compose stack can have storage outside the paths covered by that job, so check the coverage before relying on it.
Restoring a completed backup changes the app’s current data and interrupts service. With agent 0.6.25, file restoration verifies the archive before stopping the app for the data exchange, keeps it stopped while a restore job may still be writing, and recovers the previous data if the exchange fails. Existing servers need an explicit agent update. Replaced data is kept aside, using disk space until explicitly removed. Follow the app backup guide for coverage, maintenance planning and recovery checks.
For eligible standalone PostgreSQL, MySQL, MariaDB and MongoDB catalog apps, the backup now exports the database and verifies the export by restoring it into an isolated temporary database before upload. This differs from a file archive and from managed-binding recovery. Image eligibility and consistency limits vary by engine; apps with an internal bundled database are outside this standalone workflow. Read verified database app backups before planning recovery.
Test a second copy in another country
For the reviewed Memos 0.31.0 and Uptime Kuma 2.5.5 recipes, Protect this app in My Apps guides standby creation, pairing and the first restore drill. Each write needs your confirmation. A verified drill checks a dated cold copy; it does not continuously replicate newer writes or move visitors to the standby. Use the failover guide before choosing the second server. Other catalog apps require their own data-copy review.
Move to another server when needed
Follow the app migration guide to prepare a compatible destination, then restore the app backup into it. The source remains in place while you check the destination. Plan traffic changes and handle data written after the backup before retiring the source. This is a migration workflow, not a promise of uninterrupted service or automatic synchronization.
Start now
Spin up an offshore VPS and install from the catalog, or let your assistant do it from the chat after you connect with OAuth.