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
- 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, point a custom domain at it or take a free imprezaapps.com subdomain. HTTPS is issued automatically for that web route. Most web apps can also publish a .onion address. 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. Save any generated or supplied credentials in your password manager. Check that the app is ready and access is configured before sharing its address; account setup differs by application.
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
With Agent 0.6.35, the deployment result says whether the existing public HTTPS check confirmed the app’s address and warns when the public route could not be applied. The app stays installed in either case. Read the warning and check the app and route before retrying instead of installing another copy blindly.
This is one check at deployment time, not continuous availability monitoring. It does not verify every application function or certify a Tor route. A newly returned .onion address can take several minutes to answer; inspect the Tor publishing steps separately. Existing servers need an explicit Agent update to receive the 0.6.35 behavior.
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.
Most catalog apps can publish a Tor v3 .onion address alongside the public hostname, or instead of it. A password manager or a private search instance reachable only over Tor is a genuinely stronger setup. 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.