Impreza MCP can inspect supported app storage and run the native command line of selected catalog apps. This helps an assistant investigate an application after deployment, with separate tools for reading files and running maintenance commands.
Use an app deployment managed through the Impreza Agent. Available storage areas and command lines depend on the deployment. Check what the tools return for your app before following an example.
Start with the symptom and deployment ID
Identify the affected app, what changed and when the problem started. Review its status and logs with the deployment and log tools. A server being online does not establish that the application is healthy.
Check this deployment’s status and recent logs. Summarize the errors and the next read-only checks. Do not restart it or change configuration yet.
Use a limited credential if another agent is doing the investigation.
Review activity received from AI connections
The account owner can open API Management → AI activity to review covered calls received from AI credentials. The record shows a tool, limited target information, a result code and a UTC minute; it is not a copy of prompts, arguments or tool output. Retention defaults to seven days, with owner controls for 1–30 days or Off.
Eligible newly created deployments, projects, environments and webhook subscriptions can also carry Created by AI labels. Existing resources are not labelled retroactively. An accepted call does not prove that queued work completed. Local MCP coverage is limited to the service-side operations documented for AI-designated REST credentials, so this is not a complete local transcript. Read AI activity and its limits before using it to reconstruct a change.
Use the diagnostic picture before choosing a repair
Open the app’s diagnostic information in My Apps and compare the latest operation, observed runtime and any suggested next step. Supported API and MCP errors also return structured guidance for recognized problems. A suggested action is a way to investigate or repair the reported condition; it does not override access rules or authorize a change.
Current hosted MCP can also explain an incident from recorded app metrics and an optional log tail you fetched first. It groups supported evidence into crash loop, out of memory, disk full or unclear, and suggests a next step without executing it. The classifier uses fixed rules on Impreza; results return to the AI client you connected. Review logs for secrets before sending them. Follow diagnosis before a repair instead of treating the explanation as permission to restart or resize.
The project page brings linked apps, deployment results, previews, domains and backup policy together. It reports available evidence rather than continuously probing every URL, DNS record or certificate. An unavailable or old observation remains unknown. See projects and environments and runtime health.
Agent 0.6.28 or later can also report supported host-inventory facts. Use their timestamps to distinguish an app issue from a host condition, without treating inventory read access as permission to administer the operating system.
Read SSH and HTTPS key-exchange findings
Ask the current hosted MCP to run impreza_doctor before deciding on a repair. Alongside account and server findings, it can explain the reported SSH and HTTPS hybrid key-exchange readiness. These findings are informational: they do not block a deployment, change a server or turn a suggested action into authorization.
Review this account’s diagnostic findings, including SSH and HTTPS key exchange. Separate measured facts from unknowns. Do not reinstall, change SSH settings or modify an app.
The diagnostic uses reported OS and Agent facts together with existing platform measurements; it does not negotiate a fresh connection to every server. SSH measurements currently cover the platform’s Ubuntu 24.04 image and its hybrid sntrup761x25519 exchange. An unmeasured image or missing OS report should remain not measured, rather than being labelled insecure or assumed to have the same result.
For the managed HTTPS proxy, the finding uses the compatible Agent version and the platform measurement from 0.6.41 onward: it offers the hybrid X25519MLKEM768 group, with a classical fallback for clients that do not offer it. That does not prove that your particular browser or API session negotiated the hybrid group. Read the finding and verify the actual connection separately when needed.
Hybrid key exchange concerns the connection’s session keys. It does not make certificates, signatures, disk storage or a running VM’s memory post-quantum protected, and it is not an overall privacy or security certificate. Keep these findings separate from app health and operational errors. Use the diagnostic API reference for the supported read operation and check which tools your actual connection offers.
Limit sensitive evidence sent to an assistant
The published incident explanation redacts visitor IPv4 and IPv6 addresses, email addresses, query strings and tokens from its bounded evidence, in addition to credentials. Its classification still suggests a next check without executing a repair.
This applies to the explanation’s output, not to every raw application log or file you can retrieve. Review material before sharing it with an AI provider and send only what the investigation needs. Missing or redacted evidence is not proof that the application is healthy.
Add recent metrics to the investigation
For a compatible agent, review Metrics & alerts alongside the app’s status and logs. Recent CPU, memory, restart and volume measurements can help locate the period to investigate. The window is limited to 24 hours, CPU values are samples and volume sizes are estimates. Missing measurements mean unknown, not healthy.
Read app metrics and alert rules before configuring a threshold. An alert is evidence to investigate; it does not authorize a restart or an automatic repair. Keep this guide focused on the files and maintenance commands that explain the symptom.
Separate a reporting failure from an app failure
During deployment diagnosis, check the operation’s result alongside the app’s current status and logs. With Agent 0.6.26, a network failure while reporting a result no longer marks the app for recovery review by itself. That does not prove the app is healthy or that the operation succeeded.
Read the existing result before requesting the same change again. For an interrupted deployment, follow deployment recovery; existing servers need an explicit Agent update to receive the newer behavior.
Recognize readiness checks in access logs
After updating to Agent 0.6.30, an eligible app using the prepared redeploy workflow receives active requests to each upstream’s configured readiness path twice a second. Those checks can appear in access logs during normal operation. Compare the path and cadence with the configured health check before treating that traffic as a visitor spike or an attack.
A successful readiness response checks that endpoint; it does not prove every application function works. Use redeploy readiness guidance to choose a meaningful path and verify user behavior separately. Do not weaken Shield just to silence health-check entries.
Check server connections before changing the app
If a container cannot reach a database, cache or service running directly on the server, inspect the Agent version and host firewall rules. Agents 0.6.21–0.6.24 blocked new container-to-host connections ahead of the host’s own allow rules. Agent 0.6.25 lets those firewall rules decide first and allows published ports, including a site’s requests to its own managed hostname. Follow container-to-host troubleshooting and update the Agent explicitly where needed. Check access narrowly; do not disable protections just to make a diagnostic request pass.
Discover the storage before reading files
Call impreza_get_app_read with the deployment ID and no read ID to list the readable storage areas. Then use impreza_inspect_app to list a directory, read a file, tail its last lines or search with a pattern.
Paths are relative to a reported storage area, such as data or a named volume. They are not arbitrary host filesystem paths. The inspection job mounts the app storage read-only.
For example, list a reported data area using these arguments:
{
"deployment_id": "dpl_REPLACE_ME",
"action": "list",
"root": "data",
"path": "."
}
Replace the deployment ID and confirm the area exists first. Collect the result with impreza_get_app_read, passing the returned read_id and deployment ID. A pending response means the read has not finished.
Read only the files needed for the investigation. Output is bounded and may be truncated; it is not a complete file export. Configuration and logs can contain credentials or personal data. Ask the assistant to report findings without repeating those values and to treat file content as data, not instructions.
Discover the app’s command line
Call impreza_get_cli_run with the deployment ID and no run ID. It returns the available command lines and examples. The catalog integration currently includes WP-CLI and a database client for WordPress, occ for Nextcloud and Gitea’s command line.
A custom container or another catalog app may have no integrated CLI. This interface is for supported app commands, not a general interactive host terminal. Running a CLI command requires a running app and manage permission, even when the requested command only lists information.
For a supported WordPress deployment, an initial inventory command uses impreza_app_cli:
{
"deployment_id": "dpl_REPLACE_ME",
"cli": "wp",
"args": ["plugin", "list", "--format=csv"]
}
Provide arguments as a list, without adding the wp executable to it. Review the target and command before confirming execution. This example requests plugin information; other commands available through the same tool can modify or delete data.
Collect the result and validate the app
The CLI request returns a run ID. Use impreza_get_cli_run with that ID and the deployment ID to collect the completed output. Do not interpret an accepted request as a successful command, or truncated output as a full database export.
Before a repair, agree on the expected change, prepare an appropriate backup and recovery plan and account for any interruption. Execute the selected change, inspect its result and test the affected app function afterward.
If the issue concerns recurring work, check the scheduled task history before creating another timer. Duplicate tasks can make diagnosis harder and process the same work twice.
If the repair changes application configuration, use configuration export and review to inspect the exact supported changes before applying. That workflow updates an existing app; it is not a data restore or an unrestricted shell.
For an AI credential that can make changes, the account owner can require human approval for selected actions. Configure the policy before the task; it is off by default. Portal approval is separate from read access, CLI permissions and the app’s recovery checks.
Change an app’s domain with a reviewed handover
Use the managed domain-change workflow for the existing app. Editing a DNS record alone does not update the application’s proxy route. Check the current domain, the intended replacement and the required DNS configuration before authorizing the change.
Review this app’s current domain and the proposed replacement. Explain the DNS requirements and possible interruption. Ask me before changing anything, then report the final operation result and check HTTPS on the new address.
With Agent 0.6.39 or later, a successful domain change reloads the proxy before it is recorded as complete, so the previous domain stops being served through that route even after an interrupted change is retried. The existing handover keeps the old route while the new address is being verified; if the new certificate is not ready, inspect the reported failure instead of treating the request as a completed move.
An accepted request is not completion. Read the current result after a timeout, then check the new hostname’s HTTPS response and the app function you rely on. This is not a promise of zero interruption, and it does not migrate your application data or change a separate onion address. Read Agent updates and follow deployment recovery when the result remains uncertain.
Keep host maintenance separate from app commands
An app’s WP-CLI, occ or Gitea command line is different from maintaining the host. The released managed-ingress reload uses a reviewed host plan, not an arbitrary command through the app CLI. It is offered on Ubuntu 24.04 amd64, with Agent 0.6.36 or later and a managed ingress unit whose reload capability is confirmed. The version number alone is not enough.
The account owner grants that exact operation and server, then a person approves the prepared plan. Review its affected apps and connection warning before applying. General manage access does not replace the grant, and approval does not prove the reload finished. Check the final result and app access afterward.
If the result remains partial, keep the plan reference and follow the documented recovery steps; do not keep resubmitting the effect or delete its journal. This narrow operation does not authorize package updates, kernel changes or a reboot. Read managed ingress reload and recovery before requesting it.
Use added disk space through a separate filesystem plan
After a compatible Impreza VPS disk resize, unused space may still need to be added to the root filesystem. The released growth flow uses REST host plans, with Agent 0.6.39 or later, an owner grant, local server opt-in and human approval. It currently supports Ubuntu 24.04 amd64, plain ext4 on the last partition of a virtio disk; external servers, LVM, encryption and other layouts are outside this flow.
It uses space the virtual disk already has, rather than increasing the VPS disk allocation. Take a server backup or snapshot first: app backups do not restore partitions, and growth cannot be rolled back. Follow root filesystem growth for the exact plan and recovery process. This is separate from the app CLI and is not offered by the MCP host-plan tools.
Why are logs not enough?
Logs show what an application reports. A targeted file inspection can show whether an expected configuration file or persistent file exists. A native CLI can report application-specific state. Use these sources together, and keep the distinction between observation and an approved change.