Remedy Self-hosted AI bug fixing for regulated environments.
Define where code, incident evidence, model processing and repair execution take place before choosing a self-hosted workflow. Hosting the application yourself is only one part of that decision.
What needs to stay inside your environment?
“Self-hosted” can describe the application, Git server, repair worker, orchestration service or AI model. These are separate components. A local application can still send diagnostic data to a cloud control plane, and a local repair worker can still use a remote model.
Start with a data-flow inventory. List the source code, logs, screenshots, build artefacts, test fixtures and incident metadata the workflow would handle. Identify which information may leave the environment, which must remain local and which should never be collected. The answer determines whether a proposed architecture fits.
Remedy is designed around mapped repositories, bounded evidence and customer-governed deployment. Its full customer-hosted operating model remains subject to supported components and project validation. This page does not claim a generally available air-gapped deployment or certify regulatory compliance.
Separate the deployment questions
Use this checklist to make a self-hosting discussion concrete. The answers need to describe the complete path, including providers used for inference and operational support.
| Component | Question to resolve |
|---|---|
| Source repository | Which files can be read, and can code leave the network? |
| Incident evidence | Where are logs and screenshots filtered, stored and deleted? |
| Repair execution | Where do builds and tests run, and what can the worker reach? |
| Model processing | Which provider handles inference, and under which data terms? |
| Control plane | Where are identities, policy decisions and incident records stored? |
| Deployment | Who approves release, and which system performs it? |
| Operations | Who handles upgrades, backups, recovery and access revocation? |
Private Git does not settle model data handling
A repository can remain on a private Git server while selected files are sent elsewhere for analysis. Similarly, a diagnostic buffer can be stored locally before a permitted extract is transmitted. Assess the actual transfer and processing path rather than relying on a hosting label.
Ask for the proposed model provider, network destinations, retention arrangements and any use of customer data for training to be specified for the deployment. Where those terms have not been agreed, avoid treating an architectural intention as a contractual assurance.
The repository-connections page describes Remedy’s provider-independent design. GitHub, GitLab, Forgejo, Bitbucket and generic Git remain connector targets with availability constraints. Confirm the exact provider and authentication route for the pilot.
Keep observation and operational authority separate
Runtime monitoring can need access to service state without needing authority to change that service. A narrowly defined recovery action can have a different approval policy from source-code release. Decide what evidence and actions are permitted for each environment before enabling them.
The intended Remedy Agent model uses outbound communication and named capabilities. The Agent is in development. A planned capability model should therefore be evaluated against the actual installed build and the agreed action list; it should not be treated as a blanket permission to administer a server.
An initial evaluation can begin with application reports and approved diagnostic evidence where supported. Broader server, Docker, database and deployment connections should be added only when their status and boundaries have been confirmed. Read the integration status table for the current public labels.
Make the repair environment reproducible
An isolated worker still needs a reliable way to obtain the authorised baseline, dependencies and fixtures. Private package registries, internal services and build tools can be the limiting factors. Establish what can be reproduced without giving the worker general access to production.
Use appropriately prepared test data and inspect the information retained in outputs. Test logs can disclose details even when the original input was filtered. Define access to the candidate change, logs and artefacts for engineers and support staff.
The aim is a reviewable result: a known starting commit, a proposed change and evidence from the relevant checks. If the environment cannot run a check, the report should say so. A restricted network should not turn a missing check into a pass.
Plan release, rollback and ongoing operations
Self-hosting creates operational responsibilities alongside data control. Agree who upgrades each component, monitors its health, rotates access and restores incident records after an outage. Define the recovery process for both the customer application and the remediation service.
A customer can retain an existing CI/CD and approval process. In that arrangement, the repair tool produces evidence and a candidate while the release system remains responsible for rollout. Verify that the deployed source matches the reviewed candidate before running incident-specific checks.
A rollback or other recovery decision needs its own criteria. The repair workflow should preserve enough context for the responsible engineer to understand what ran and what remains unresolved. Read the architecture overview for the intended permission and evidence boundaries.
Evaluate suitability with the responsible team
Regulated teams need to assess their own data, contractual and operational obligations. This guide is a technical evaluation framework, not legal advice or a declaration that Remedy meets a particular certification. Security review and deployment-specific terms need to happen before sensitive information is shared.
Bring a representative application, a non-sensitive defect description, the repository location and the required network boundaries to the early-access discussion. The first decision is whether a supported, testable pilot fits those requirements.
See early-access pricing for the commercial model and about Remedy for the product’s current stage. A self-hosted deployment should be selected because its demonstrated data flow and operating model fit the organisation, not because the label sounds reassuring.
From bug report to verified fix.
See how Remedy connects evidence, diagnosis, repair, deterministic checks and production verification.
Explore the complete workflow →