A platform team decides to self-host an internal tool.
The installation begins with a familiar sequence:
create Namespace
install Helm chart
configure ingress
connect database
create administrator
The application starts.
The login page appears.
The team has successfully installed the software.
It has not yet proved that it can operate the service.
The remaining questions arrive more quietly:
Who upgrades it?
Who backs up its data?
Who restores it?
Who rotates its credentials?
Who responds when it is unavailable?
Who understands its dependencies?
Who pays for the infrastructure?
Who supports the teams depending on it?
Those questions are not secondary to self-hosting.
They are the decision.
A managed service packages software and a portion of its operating model behind a provider contract. Self-hosting brings more of that operating model inside the organisation.
The organisation may gain:
- configuration control
- data-location control
- deployment flexibility
- integration freedom
- reduced dependency on one managed service
- deeper operational knowledge
It also becomes responsible for:
- availability
- capacity
- upgrades
- security
- backups
- disaster recovery
- monitoring
- support
- lifecycle management
This is the exchange I want to keep visible:
Self-hosting buys control by transferring operational responsibility. The software may be free, but ownership never is.
That does not make self-hosting a poor choice.
It makes it a choice that should be evaluated as an operating model rather than an installation preference.
Running software is not the same as owning a service
Installing a tool proves that its components can start.
Owning the service means maintaining a dependable capability over time.
INSTALLATION
Can the software run?
OPERATIONAL OWNERSHIP
Can users continue depending on it
through change, failure and recovery?
A self-hosted service needs more than a Deployment and a Service object.
It needs:
- a defined purpose
- named consumers
- service ownership
- reliability expectations
- documented dependencies
- secure identity
- state management
- backup and restore procedures
- upgrade policy
- support paths
- retirement criteria
The difference becomes obvious after the first failure.
Suppose a self-hosted infrastructure automation platform becomes unavailable.
The platform team may lose the ability to:
- plan infrastructure changes
- apply approved changes
- access state
- publish modules
- investigate failed runs
- recover environments
The tool is not merely another internal website.
It sits in the path through which infrastructure is changed.
Its operating model must reflect that importance.
Control is the strongest argument
Self-hosting can provide meaningful control.
The organisation can decide:
- where the service runs
- where its data is stored
- how it is networked
- which identities may access it
- how it integrates with internal systems
- when upgrades occur
- how telemetry is collected
- which extensions are installed
- how long records are retained
SELF-HOSTED SERVICE
│
├── deployment control
├── data control
├── identity control
├── integration control
└── lifecycle control
This can be valuable when the platform has requirements a managed offering cannot satisfy easily.
Examples might include:
- strict network isolation
- private-only access
- custom identity integration
- self-managed encryption keys
- specialised plugins
- unusual retention rules
- operation across several cloud providers
- avoiding dependency on a provider-specific control plane
For bfstore, self-hosting may also serve a learning objective.
Operating Kafka, an observability stack or an infrastructure automation platform reveals the work hidden behind a managed-service interface.
That knowledge has value.
The important question is whether the organisation is prepared to maintain the capability after the educational novelty has worn off.
Control without capacity becomes responsibility without power
Owning the configuration does not guarantee that the team can operate it effectively.
A platform team may technically control:
- the database
- the cluster
- the certificates
- the backups
- the upgrade process
But if nobody has time to maintain them, that control becomes theoretical.
CONTROL
ability to make decisions
CAPABILITY
ability to execute those decisions
safely and repeatedly
A self-hosted platform needs enough capability to:
- diagnose failures
- perform upgrades
- restore data
- manage capacity
- handle security updates
- test changes
- support users
The tool may be open source.
The required operating knowledge is not downloaded automatically with the Helm chart.
A realistic self-hosting decision should therefore ask:
Do we have the authority?
Do we have the knowledge?
Do we have the time?
Do we have the recovery path?
Without all four, the organisation may possess the software while remaining dependent on a very small number of people who understand it.
That is not resilient ownership.
It is concentrated memory.
The licence cost is only one cost
A self-hosted tool may have no licence fee.
That can make the comparison appear simple:
SELF-HOSTED
£0 licence
MANAGED
monthly subscription
The real comparison is broader.
A self-hosted service may require:
- compute
- storage
- databases
- load balancers
- network transfer
- backup storage
- monitoring infrastructure
- engineering time
- incident response
- upgrade work
- security maintenance
- support
TOTAL SELF-HOSTING COST
infrastructure
plus
engineering labour
plus
operational risk
plus
recovery capability
The managed-service price may include some of those responsibilities.
Not all managed services provide equal support, availability or portability, but the comparison should reflect the complete service rather than the visible invoice line.
A useful cost question is not:
Which option has the lower monthly bill?
It is:
Which option provides the required control and reliability at an acceptable total cost of ownership?
Engineering time is a platform resource
Time spent operating internal tooling is time not spent on other platform work.
A team self-hosting several systems may need to maintain:
Kubernetes
Kafka
observability
infrastructure automation
developer portal
secret management
policy engine
container registry
Each system has:
- releases
- security advisories
- configuration changes
- capacity requirements
- failure modes
- backup needs
The work accumulates.
ONE SELF-HOSTED TOOL
manageable operational surface
TEN SELF-HOSTED TOOLS
interacting operational portfolio
The organisation should consider opportunity cost.
Could the same engineering time produce more value by improving:
- deployment safety
- workload identity
- recovery automation
- developer self-service
- application reliability
- platform documentation?
Self-hosting is not automatically wasteful.
It should compete honestly with the other work the team could perform.
The person cost is easy to hide
A tool may appear inexpensive because one engineer maintains it informally.
That engineer:
- remembers the installation
- understands the certificate arrangement
- knows which database tables matter
- performs upgrades manually
- recognises the strange log message
- knows where the backup lives
The service appears low cost.
The cost has been concentrated inside one person.
UNDOCUMENTED KNOWLEDGE
│
▼
HIDDEN OPERATIONAL DEPENDENCY
A sustainable service should not rely on one person’s memory.
Ownership needs:
- documented architecture
- repeatable deployment
- runbooks
- shared access
- tested backups
- upgrade records
- incident history
- more than one capable operator
A service maintained through invisible effort is not free.
Its invoice has simply been written in human dependency.
State determines the recovery problem
Some self-hosted tools are nearly stateless.
Others contain critical state.
Examples include:
infrastructure state
pipeline history
service ownership metadata
dashboard definitions
alert rules
user configuration
secrets
access policies
audit records
The recovery design should begin by identifying which state matters.
APPLICATION BINARY
usually replaceable
CONFIGURATION
should be reproducible
DATABASE STATE
may require backup and restore
SECRET MATERIAL
requires protected recovery
A Kubernetes Deployment can be recreated from Git.
That does not restore the database behind it.
A Helm release can recreate application resources.
That does not restore users, projects, histories or policies.
Self-hosting often exposes a useful distinction:
Reproducible infrastructure can recreate the service container. Recoverable state recreates the service users actually depended on.
A backup is only a recovery claim
A scheduled backup job is not proof that the service can be recovered.
The backup may be:
- incomplete
- corrupted
- encrypted with a missing key
- stored in the same failure domain
- incompatible with the current software version
- missing configuration required for restoration
A recovery test should prove:
backup can be located
backup can be decrypted
backup can be restored
application can start
users can authenticate
critical data is present
service behaviour works
For a self-hosted infrastructure automation service, the test might include:
- restoring its database
- restoring encryption material
- reconnecting source repositories
- accessing infrastructure state
- running a plan against a test environment
For an observability system, it might include:
- restoring dashboards and alert rules
- recovering metadata
- confirming that new telemetry can be ingested
- confirming that retained telemetry is queryable where recovery requires it
The required recovery depth depends on the service promise.
Backup location is part of the failure model
A service and its backup should not depend entirely on the same failure boundary.
Weak arrangement:
CLUSTER
application
database
backup volume
If the cluster or storage system is lost, all three may disappear together.
A stronger design may use:
PRIMARY ENVIRONMENT
│
▼
ENCRYPTED BACKUP
│
▼
SEPARATE ACCOUNT OR STORAGE BOUNDARY
The backup design should consider:
- account compromise
- regional failure
- accidental deletion
- ransomware
- credential loss
- provider outage
More separation can improve resilience.
It can also increase cost and operational complexity.
The choice should follow a defined recovery objective rather than a general belief that more copies are always better.
Self-hosted services need SLOs too
Internal tooling often lacks formal reliability objectives.
The team monitors whether the Pod is running.
Users experience a different service.
Suppose the developer platform offers an infrastructure execution capability.
A meaningful SLO might say:
Over a rolling 28-day period, 99.5% of valid development infrastructure runs should begin within five minutes and complete without platform-induced failure.
The indicator should distinguish:
USER ERROR
invalid configuration
from
PLATFORM ERROR
runner unavailable
state backend inaccessible
controller failure
Other self-hosted platform SLOs might protect:
- GitOps reconciliation delay
- telemetry ingestion
- dashboard availability
- service-template creation
- secret retrieval
- deployment execution
The objective should represent the internal user journey.
PLATFORM COMPONENT HEALTH
is supporting evidence
PLATFORM USER OUTCOME
is the service promise
A self-hosted tool deserves the same reliability discipline as the workloads that depend on it.
Availability architecture should match the promise
It is tempting to deploy every internal tool with:
- several replicas
- multi-zone storage
- automated failover
- cross-region recovery
That may be justified.
It may also be expensive overengineering.
The architecture should follow the service’s importance.
Questions include:
How long can users tolerate an outage?
Can existing workloads continue running?
Does the outage block production recovery?
Can operators use an alternative path?
How quickly must state be restored?
A developer portal may tolerate a short outage when its underlying Git workflows remain available.
A secret-management system may sit directly in the runtime path and require stronger availability.
An infrastructure state service may not be required for every running application request, but its loss could block recovery and change.
RUNTIME CRITICALITY
Does failure stop current service?
CONTROL-PLANE CRITICALITY
Does failure stop change or recovery?
Both matter.
They may justify different reliability designs.
The control plane needs a recovery path outside itself
A platform tool should not be the only mechanism capable of restoring that platform tool.
Suppose all infrastructure changes must run through a self-hosted automation service.
The service fails because its database is unavailable.
Recovery requires changing the database infrastructure.
The only approved path for changing infrastructure is the failed service.
AUTOMATION PLATFORM FAILED
│
▼
PLATFORM CHANGE REQUIRED
│
▼
AUTOMATION PLATFORM REQUIRED
That circular dependency needs an escape route.
A recovery model may include:
- break-glass cloud access
- documented local Terraform execution
- protected emergency state access
- manually invokable recovery automation
- isolated bootstrap credentials
The escape route should be:
- narrow
- audited
- protected
- tested
- used only when required
Self-service and GitOps improve ordinary operations.
Recovery still needs a path that survives failure of the ordinary control plane.
Bootstrapping creates a trust boundary
A self-hosted tool may manage the infrastructure on which it runs.
For example:
TERRAFORM AUTOMATION PLATFORM
manages cloud infrastructure
including
its own cluster dependencies
Something must create the original environment.
The bootstrap process may provision:
- network
- cluster
- database
- workload identity
- secret storage
- the tool itself
BOOTSTRAP LAYER
│
▼
SELF-HOSTED PLATFORM
│
▼
ONGOING INFRASTRUCTURE
The boundary should be explicit.
The same resources should not be managed accidentally by both bootstrap automation and the platform after handover.
The organisation should know:
- which state owns the bootstrap resources
- how that state is recovered
- which credentials are required
- how the platform is reinstalled
- where its data is restored
A platform cannot be considered reproducible when the answer is:
The tool manages everything.
We no longer remember how the tool was created.
Upgrades are part of the service lifecycle
Self-hosted software does not remain still.
New releases may include:
- security fixes
- database migrations
- API changes
- configuration changes
- deprecated features
- dependency updates
An upgrade process should answer:
Which versions are supported?
How are releases reviewed?
Where are upgrades tested?
How is state backed up first?
Can the change be rolled back?
Does rollback include the database?
How are users notified?
A useful flow might be:
READ RELEASE NOTES
│
▼
BACK UP STATE
│
▼
TEST UPGRADE
│
▼
VERIFY USER JOURNEY
│
▼
PROMOTE
│
▼
OBSERVE
The test should cover more than whether the container starts.
It should verify:
- authentication
- critical workflows
- integrations
- data migration
- telemetry
- backup compatibility
Rollback may not be simple
A container image can often be changed back.
A database migration may be irreversible.
APPLICATION VERSION
can return to v1
DATABASE SCHEMA
may already have moved to v2
Upgrade planning should distinguish:
- application rollback
- configuration rollback
- data rollback
- restore from backup
- forward repair
The recovery path may be:
failed upgrade
restore database backup
restore previous configuration
deploy previous application
verify service
That can be slower and riskier than changing one image tag.
The platform team should understand the vendor or community project’s migration behaviour before production depends on it.
Security ownership moves inward
A managed service provider usually handles some layers of security.
With self-hosting, more layers become the organisation’s responsibility.
These may include:
- base images
- operating systems
- Kubernetes configuration
- application patches
- database patches
- ingress
- certificates
- authentication
- session security
- secret storage
- audit logging
SELF-HOSTED SECURITY
application
runtime
cluster
network
identity
data
operations
The project may publish a security fix.
The organisation must still:
- notice it
- assess exposure
- test the release
- deploy it
- verify the result
The time between disclosure and remediation becomes part of the risk model.
A self-hosted tool with slow patching may provide more nominal control but less practical security than a well-operated managed alternative.
Control is valuable only when it produces timely action.
Identity integration deserves product treatment
A small self-hosted installation often begins with local users.
administrator
developer-one
developer-two
As adoption grows, local identity becomes difficult to manage.
The service may need integration with:
- an identity provider
- single sign-on
- groups
- role mapping
- short-lived sessions
- multi-factor authentication
- audit identity
IDENTITY PROVIDER
│
▼
SELF-HOSTED TOOL
│
▼
ROLE AND PROJECT ACCESS
The design should answer:
- who may administer the service?
- how are users removed?
- how are service accounts represented?
- can access be traced to a person?
- which roles are available?
- how is emergency access controlled?
A self-hosted platform tool often holds powerful authority.
Its identity design should not remain in demonstration mode after the demonstration becomes production.
The tool should not receive unlimited authority
An infrastructure platform may need cloud permissions.
A GitOps controller may need cluster permissions.
An observability Collector may need backend write access.
The easy configuration is broad authority:
administrator access
cluster-admin
all resources
The safer design bounds permissions by responsibility.
INFRASTRUCTURE AUTOMATION
manage approved accounts and resources
GITOPS CONTROLLER
manage selected Namespaces and objects
TELEMETRY COLLECTOR
write to approved observability destinations
The tool is part of the trust model.
Compromise may allow an attacker to:
- deploy workloads
- read state
- access secrets
- alter infrastructure
- disable telemetry
- modify policy
Self-hosting increases the importance of understanding what the service can do, not only where its containers run.
Configuration should be reproducible
A self-hosted service should not depend on manual configuration hidden inside its user interface.
Important settings may include:
- authentication
- projects
- access roles
- retention
- integrations
- runners
- plugins
- policies
- notifications
Where supported, these should be managed through:
- declarative configuration
- APIs
- version-controlled automation
- reproducible bootstrap scripts
SOURCE-CONTROLLED CONFIGURATION
│
▼
AUTOMATED APPLICATION
│
▼
SELF-HOSTED SERVICE
Some state will remain operational or user-generated.
The goal is to separate:
INTENDED CONFIGURATION
reproducible
RUNTIME STATE
backed up and recoverable
Manual configuration may still be necessary.
It should be documented and minimised.
A platform service is difficult to recover when nobody knows which checkboxes transformed the default installation into the production one.
Observability tooling must observe itself
A self-hosted observability platform creates a recursion problem.
OBSERVABILITY PLATFORM
monitors workloads
Who monitors the observability platform?
Possible approaches include:
- a separate minimal monitoring path
- local health checks
- external synthetic checks
- cloud-native baseline alerts
- independent log storage for critical failures
The goal is not to duplicate the complete observability stack.
It is to retain enough visibility to detect when the primary system is failing.
For example:
Can telemetry be ingested?
Are queues filling?
Are collectors dropping records?
Is storage available?
Can users query recent data?
Are alerts being evaluated?
Missing telemetry should not be interpreted automatically as healthy applications.
The observability system may simply have stopped receiving evidence.
Capacity is now the platform team’s problem
Managed services often scale within documented boundaries.
A self-hosted service requires explicit capacity planning.
The team needs to understand:
- request rate
- data volume
- storage growth
- queue depth
- retention
- concurrent users
- reconciliation workload
- background jobs
For an observability stack:
telemetry volume
multiplied by
retention
multiplied by
replication
can create significant storage requirements.
For Kafka:
message throughput
multiplied by
retention
multiplied by
replication factor
affects disk and network demand.
For infrastructure automation:
concurrent runs
provider latency
repository size
plan output
state operations
affect runner and database capacity.
Capacity decisions should follow measured workload and growth expectations.
Self-hosting does not remove scaling limits.
It moves them closer to the team.
Cost can move rather than disappear
A managed service may expose a clear subscription fee.
A self-hosted alternative may distribute cost across:
cluster nodes
database
storage
network transfer
backups
engineering labour
Because these costs appear in different places, the tool can feel cheaper than it is.
Shared infrastructure complicates attribution.
A Kubernetes cluster may host several platform tools.
The organisation still benefits from estimating:
- baseline cost
- variable cost
- storage growth
- backup cost
- operational effort
- expected incident cost
Cost should be revisited after real use begins.
A design that appeared economical at low volume may change dramatically when:
- telemetry retention grows
- Kafka traffic increases
- high availability is introduced
- database replicas are added
- backups move across regions
Self-hosting gives more control over the cost model.
It does not guarantee a lower cost model.
Support moves from vendor queue to internal queue
A managed service may include formal support.
A self-hosted open-source project may provide:
- documentation
- community forums
- issue trackers
- optional commercial support
The internal platform team remains the first support layer for users.
APPLICATION TEAM
│
▼
PLATFORM TEAM
│
▼
PROJECT COMMUNITY OR VENDOR
The team needs to decide:
- which hours are supported
- which incidents are urgent
- how users request help
- which versions are supported
- who investigates bugs
- when upstream issues are opened
- whether commercial support is justified
An internal service without a support model may work well until another team depends on it.
At that point, every unexplained failure becomes an urgent direct message to whichever engineer last touched the Helm values.
Open source does not remove dependency
Self-hosting can reduce dependency on one managed platform.
It does not create independence from every external party.
The organisation still depends on:
- the upstream project
- container registries
- package repositories
- maintainers
- plugins
- underlying databases
- cloud infrastructure
A project may:
- change licence
- slow development
- remove features
- introduce breaking changes
- become unmaintained
- suffer a supply-chain compromise
The platform team should consider:
Is the project active?
Is the release process trustworthy?
Is security response visible?
Can data be exported?
Can configuration be migrated?
Is there a credible alternative?
Self-hosting can improve exit options when data formats and APIs are open.
It does not make migration effortless.
Portability should be tested, not assumed
A self-hosted tool may run on Kubernetes in several clouds.
That suggests portability.
The actual deployment may depend on:
- one cloud’s load balancer
- one identity mechanism
- one database service
- one object-storage API
- one DNS implementation
- one secret manager
PORTABLE APPLICATION
may still rely on
NON-PORTABLE PLATFORM SERVICES
There is nothing inherently wrong with using cloud-specific capabilities.
The organisation should know where the dependency exists.
For bfstore, a self-hosted tool might use:
- Kubernetes for compute
- an external MySQL or PostgreSQL database
- object storage for artefacts or backups
- workload identity for cloud access
- private DNS
- a cloud load balancer
A future move to another cloud would require adapting those integrations.
The self-hosted application is one layer of portability, not the entire answer.
Not every tool should be self-hosted
A deliberate platform strategy can mix managed and self-hosted services.
Possible reasons to choose managed include:
- the capability is undifferentiated
- the team lacks operating capacity
- the service requires strong availability
- security patching must be rapid
- the managed option has acceptable cost
- the integration is straightforward
- the exit path is understood
Possible reasons to self-host include:
- configuration control is important
- data handling requires it
- custom integration is necessary
- managed cost is unsuitable at expected scale
- learning is an explicit objective
- provider independence has real value
- the team can own the service properly
SELF-HOST
when control and learning
justify ownership
MANAGED
when delegated operations
create more value
The goal is not ideological purity.
It is a platform portfolio whose responsibilities match the organisation’s goals and capacity.
Learning changes the calculation
For a commercial production platform, self-hosting may be rejected because the operational burden exceeds the benefit.
For a learning project such as bfstore, the burden can be part of the benefit.
Operating a tool can teach:
- state management
- backup and recovery
- workload identity
- high availability
- capacity planning
- upgrade discipline
- observability
- incident response
That learning should still be structured.
A useful educational deployment should include:
installation
security baseline
observability
backup
restore test
upgrade test
failure exercise
cost review
Otherwise the exercise teaches only how to install the software.
The most valuable lessons often begin after the first successful login.
A possible bfstore ownership model
bfstore may self-host several platform capabilities for learning and control.
Infrastructure automation
A self-hosted automation platform manages OpenTofu or Terraform runs.
It needs:
- repository integration
- workload identity
- protected state
- runner isolation
- database backup
- audit history
- recovery access
Developer portal
Backstage provides:
- service ownership
- documentation
- templates
- operational links
- API discovery
Its outage should not necessarily stop GitOps or existing workloads.
Its data and configuration still require recovery.
Crossplane
Crossplane may expose platform APIs through Kubernetes.
It needs:
- bounded cloud identity
- provider lifecycle management
- reconciliation monitoring
- recovery procedures
- clear ownership boundaries with Terraform
Kafka
Self-hosted Kafka supports application messaging.
It needs:
- broker capacity
- replication
- storage planning
- certificate management
- topic policy
- backup or recovery design
- failure testing
Observability
A self-hosted stack stores logs, metrics and traces.
It needs:
- telemetry routing
- capacity management
- retention
- backup decisions
- pipeline monitoring
- access control
- an independent signal when observability itself fails
BFSTORE SELF-HOSTED TOOLING
│
├── infrastructure automation
├── developer portal
├── Crossplane
├── Kafka
└── observability
These tools do not all need identical reliability or recovery objectives.
Each should have its own service profile.
A service ownership record
For every self-hosted tool, I would record:
Purpose
Which user problem does this service solve?
Consumers
Which teams and workflows depend on it?
Owner
Who operates and supports it?
Criticality
What stops working when it fails?
State
Which data must survive?
Dependencies
Which databases, storage systems,
identity providers and networks does it require?
Reliability
Which user-facing SLO applies?
Recovery
How is the service restored,
and when was this tested?
Security
Which authority does the tool hold?
Upgrade
How are releases tested and promoted?
Cost
What are its infrastructure
and operating costs?
Exit
How can data and users move elsewhere?
This turns self-hosting from an isolated deployment into an explicit platform commitment.
A decision test
Before self-hosting a platform tool, I would ask:
Control
Which specific control do we gain?
Value
Why does that control matter?
Capability
Can the team operate the service
through failure and change?
State
Which information must be protected
and recovered?
Reliability
Which user journey depends on it?
Security
Which privileged authority will it hold?
Upgrades
How will security and feature releases
be tested and applied?
Cost
What is the complete cost,
including engineering time?
Support
Who responds when users are blocked?
Bootstrap
How is the service recreated
when it cannot recreate itself?
Exit
Can we migrate away without
losing critical state?
A self-hosting decision is stronger when each answer is concrete.
We prefer control.
is not enough.
The team should be able to say which control, why it matters and how the resulting responsibility will be carried.
The mental model I am keeping
My earlier model was:
SELF-HOSTING
run the open-source version ourselves
to save money and gain control
The stronger model is:
PLATFORM NEED
│
▼
OPERATING DECISION
│
┌────────────────┴────────────────┐
│ │
▼ ▼
MANAGED SERVICE SELF-HOSTED
│ │
▼ ▼
DELEGATED OPERATIONS INTERNAL OWNERSHIP
│ │
├── provider controls ├── configuration
├── provider limits ├── availability
├── subscription cost ├── upgrades
└── support contract ├── security
├── recovery
├── capacity
└── support
Control answers:
Which decisions can we make directly?
Cost answers:
Which infrastructure, labour
and risk do we pay for?
Operational ownership answers:
Who maintains the service
after installation?
Reliability answers:
Which user experience
must remain dependable?
Recovery answers:
Can the service and its state
be restored together?
Security answers:
Which authority does the service hold,
and how is it protected?
Upgrade policy answers:
How will the service remain
supported and secure?
Bootstrap answers:
How can the control plane
be recovered when it is unavailable?
Exit planning answers:
Can we leave without losing
data, configuration or authority?
Self-hosting can be a strong platform choice.
It can provide control over data, identity, integration and lifecycle.
It can deepen engineering knowledge.
It can create portability and reduce dependence on a managed control plane.
It can also create fragile services maintained by hidden labour, incomplete backups and one engineer’s excellent memory.
The difference is not whether the software starts.
The difference is whether the organisation accepts and supports the operating responsibility that begins when it does.
Self-hosting is not the absence of a service provider. It is the decision to become one for your own users.
That is the standard I want to apply.
Not:
Can we install it?
But:
Can we secure it?
Can we observe it?
Can we upgrade it?
Can we recover it?
Can we support it?
Can we afford to own it?
When the answer is yes, self-hosting can provide valuable control.
When the answer is uncertain, the monthly subscription may not be the expensive part of the alternative.