Decide whether to self-host a tool

Self-hosting is an operating model, not a feature checkbox. This decision record keeps the useful question—who should own which responsibilities—separate from enthusiasm for a particular product.

State the decision

Name the job the tool must do, the people affected, the decision owner, the review date, and the alternatives. Include “keep the current process” and “use a managed service” when they are credible options. A repository found, installed, or tested is not adopted until the owner records that decision.

Use one outcome: explore, run a bounded trial, adopt, defer, or decline. Attach conditions and a revisit date rather than leaving “maybe” as permanent infrastructure.

Test the operating boundary

Answer these questions before comparing features:

• Data: What enters the system? Where are primary data, logs, backups, and exports stored? What must never enter it?
• Exposure: Is the service private, internet-facing, or reachable through another control plane? Which ports and trust boundaries exist?
• Identity: How are users, administrators, service accounts, recovery access, and revocation handled? Are secure defaults available?
• Supply chain: Can releases, images, dependencies, signatures, provenance, and security advisories be traced to an authoritative source?
• Updates: Who evaluates and applies security fixes? What is the supported upgrade path, maintenance window, and rollback method?
• Recovery: What is backed up, encrypted, retained, and restored? Has a restore been executed in the intended environment?
• Operations: Who receives alerts, owns incidents, renews certificates, monitors capacity, and handles absence or turnover?
• Exit: Is there a documented export format and tested path to migrate or remove the system?
• Cost: Include operator time, storage, backup copies, network transfer, monitoring, and expected failure work—not only compute.

Unknown answers are decision evidence. They are not automatically objections, but they must not be silently converted into “supported.”

Require evidence proportional to risk

Documentation can support claims about intended behavior. A local check supports only the tested version and environment. For a bounded trial, retain the version or digest, configuration differences, test inputs, results, failure evidence, and cleanup plan.

For software supply-chain and lifecycle questions, the NIST Secure Software Development Framework provides a common vocabulary for secure development and acquisition. CISA’s Secure by Demand guide provides questions customers can ask about a manufacturer’s product-security practices. These are reference points, not certifications and not proof that a candidate meets them.

Synthetic worked example

The fictional Patchwork Studio is considering a self-hosted task board for six people. It handles project titles and due dates, but no customer files, credentials, or regulated data. The alternatives are the current shared text file, a managed task board, and a self-hosted candidate.

The team records a bounded trial, not adoption. The trial is private-network only, uses synthetic tasks, has no production integration, and lasts two weeks. Entry conditions are a pinned release, documented administrator recovery, a supported export, an update feed, and a disposable host. Exit conditions are a completed export review, deletion of the trial data and host, and a written decision.

The candidate’s documentation describes backups and exports, but the team has not executed a restore. Alert ownership during absences is also unresolved. The trial outcome is therefore defer until a restore exercise and ownership decision occur. No reliability, security, cost-saving, or adoption claim follows from the installation.

Record the outcome

The final record should list the selected outcome, evidence reviewed, trial results if any, unresolved risks, named operational owners, review date, and reversal plan. If the result is adoption, keep the same record alive: upgrades, incidents, capacity changes, and exit readiness can invalidate the original assumptions.

Use the downloadable self-hosted tool decision record to capture the decision without turning unanswered questions into implied approval.