Beyond an Onion Address: Access, Identity and AI Operations on Your VPS

A team can publish an application at an onion address and still have unanswered questions. Who should be able to connect? What happens when a team member leaves? Which backup preserves the address if the application needs to be recovered? And does asking an AI assistant to manage that application mean the assistant’s own connection travels through Tor?

These are different operational decisions. Impreza brings infrastructure, app deployment and native Tor controls together through the portal, REST API and MCP. The useful change is not simply another way to obtain an onion URL. It is the ability to manage access, protection and identity as explicit parts of running an application on your own server.

Three onion workloads, three starting points

A public onion website is intended to be reachable by Tor visitors who know its address. Its application may offer public content, registered accounts or both. Publishing it over Tor does not decide what the application records, which external services it contacts or which actions visitors may perform.

A restricted team application has another requirement: only approved Tor clients should be able to discover and reach its service. Client authorization adds a key requirement at that network boundary. It suits teams that can configure their clients and maintain an inventory of access keys. Application accounts and roles still govern what each person can do after connecting.

A temporary Git preview is different again. It exists to review a branch, has a defined lifetime and uses server capacity alongside other apps. A preview address alone is not an authorization policy. Do not assume temporary previews inherit every control available to persistent deployments. Choose the workflow for the job instead of treating all onion URLs as equivalent.

Separate reaching the app from using the app

Imagine a small team running a project workspace. Two maintainers need regular access, and an external reviewer needs access for a limited assignment. A named Tor client key for each independently managed client makes the access list easier to inspect and individual access easier to revoke. Sharing one private key among everyone makes those decisions harder.

The workspace should still require application sign-in. A Tor key does not distinguish an editor from a reader inside the application, and it does not replace session management. Review any public hostname or listener as well: a separate route could expose the same application outside the access boundary you intended.

After adding a key, wait for the agent command to finish and test the actual result. Check one configured client and a separate client without the authorization credential. When the review ends, remove only the intended client and verify again. Removing the final authorized client makes the onion service public to Tor visitors; an empty list is not a disabled service.

Protection is a configuration choice, not a universal promise

Impreza’s eligible agent-managed apps provide standard, hardened and max profiles. Hardened adds stream limits. Max adds Tor proof-of-work controls and requires support in the installed Tor build. A nondefault profile at deployment requires the agent’s initial-profile capability, so the policy can be staged before the service is first published.

Choose a profile against your application’s behavior and visitor needs. These controls do not install application login, a WAF or per-circuit rate limiting in the web proxy. Keep application updates, capacity planning and recovery procedures in the operating plan. No profile guarantees that every attack or availability problem disappears.

Access changes restart the shared Tor daemon. Other onion connections on that server can briefly disconnect even though their containers and data remain intact. Plan changes with that shared effect in mind, and treat a queued operation as work to verify rather than a completed result.

The address has its own recovery story

A successful app backup answers whether supported application data can be restored. It does not automatically answer whether the original onion address will return. That address depends on its Tor identity. Plan for both the data and the identity before an incident forces the question.

Encrypted identity export seals the identity bundle to a recipient public key. Keep the recipient private key locally and securely, then save the completed export when it is retrieved. Retrieval is one-time. If the response is lost, request another export; a saved command ID is not a substitute for the encrypted bundle.

Recovery also requires the documented identity files and a valid destination plan. Existing address reservations remain after failure, uninstall or rotation. Contact support before moving an already-used identity to another deployment. Deleting the old app does not automatically release the address, and a timeout is not proof that its service stopped.

Rotation solves a different problem: it changes the address. Existing links then need updating. It is not a shortcut for preserving continuity during a move. Recheck app data, visitor access and the resulting address after any recovery or identity operation.

AI operations and Tor transport are separate choices

MCP lets a compatible assistant perform supported operations under your account permissions. You can use it to inspect access settings or help operate an app that publishes through Tor. That does not by itself mean the assistant’s connection to Impreza is using Tor.

A client connecting through the hosted onion MCP endpoint must support that endpoint and a Tor proxy. Opening browser consent in Tor Browser alone does not route the client’s token exchange or later MCP requests. OAuth issuer and resource validation still matter; the logical resource does not become a different value simply because transport uses an onion address.

The MCP over Tor guide lists the portal, API, hosted MCP and documentation onion addresses and explains the connection requirements. Tor affects the network path, not what your AI provider receives in prompts, tool arguments and results. Keep private keys out of shared conversations and use permissions appropriate to the task.

Start with one application and a recovery plan

For the team workspace, begin with a supported server and enough resources for the app, database and Tor processes. These controls require Impreza Agent 0.6.19 or later and the relevant advertised capabilities. Existing agents need an explicit update. Local MCP requires 0.41.0 or later; the portal, REST API and hosted MCP offer supported operations as well.

This is distinct from the aaPanel workflow with Tor Manager and Onion Guard. Confirm the environment before selecting a plan. Then add a test client, verify the restricted connection, retain application authentication and prepare separate app-data and identity backups.

Use the authorization guide for the access procedure and the identity recovery guide for custody requirements. For infrastructure planning, see private onion app hosting. The goal is an application whose access and recovery behavior you have tested, with clear decisions about what your assistant may operate.