Self-Hosting

How Self-Hosting Works

With Self-Hosting, a digital service is not operated entirely by an external software provider.
Instead, the user or organization takes responsibility for essential parts of its operation.

These can include, for example:

• installation
• configuration
• updates
• user management
• access control
• certificates
• network operation
• monitoring
• backups
• recovery
• fault analysis
• migrations

How many of these tasks are actually handled in-house differs from system to system.
Self-Hosting therefore does not describe a single fixed technical operating model.

The Server Does Not Have to Be in the Basement

Self-Hosting is often associated with owning hardware.
However, this is not necessary.

A service can, for example, be operated on:

own physical server
rented root server
virtual machine at a hosting provider
rented infrastructure in a data center

In all of these cases, the actual application operation can take place under one’s own responsibility.

What matters less is who owns the hardware than the question:

Who controls the operation of the service?

Self-Hosting Has Degrees

There are many intermediate stages between completely self-operated and completely outsourced.

One example:

Hardware           → data center
Virtualization     → hosting provider
Operating system   → own responsibility
Application        → own responsibility
Data               → own responsibility
Backup             → own responsibility

Another model could look like this:

Hardware           → cloud provider
Operating system   → managed service
Database           → managed service
Application        → own responsibility

Whether the second variant is still described as Self-Hosting also depends on the definition being used.

For practical decisions, the label is often less important than the concrete question:

Which layers do we control ourselves and which do we not?

Control Is Traded for Responsibility

Self-Hosting often provides additional technical control.

For example, one can decide:

• when updates take place
• which version is used
• which extensions are installed
• where data is stored
• which interfaces are reachable
• which protocols are used
• how backups are created
• how long data is retained

This control, however, comes at a price.

Someone must now be responsible for those same decisions.

From:

The provider takes care of it.

becomes:

We need to know who takes care of it.

Control and responsibility are therefore difficult to separate in Self-Hosting.

Updates Are Part of Operation

A self-hosted application does not remain reliable simply because it was successfully installed once.
Software changes.
Security vulnerabilities are discovered.
Dependencies receive new versions.
Certificates expire.
Operating systems reach the end of their support life.

A Self-Hosting concept therefore also needs an answer to:

How do we identify necessary updates?
How do we test changes?
Who performs them?
How can we roll back?

The effort therefore does not arise only during installation.
It arises throughout the entire operating life.

Backup Is Not Restore

A common operational requirement is:

We have backups.

This initially describes only that data is backed up somewhere.

For actual recoverability, further questions are relevant:

• Are the backups complete?
• Are they readable?
• Are the required keys available?
• Is recovery documented?
• Has it been tested?
• How long does it take?
• How much data is lost between the last backup and the failure?
• Is the necessary configuration also backed up?

A backup that cannot be reliably restored has only limited practical value.
Self-Hosting therefore also means taking responsibility for recoverability.

Security Does Not Come from Location

A server of one’s own is not automatically more secure than an external service.

A self-hosted system can, for example, be:

unpatched
misconfigured
poorly monitored
without functioning backups

A professionally operated external service can be considerably better positioned in these respects.
Conversely, Self-Hosting can make it possible to tailor security decisions more specifically to one’s own requirements.

Security therefore does not result from:

self-hosted = secure

but from the actual architecture and operational quality.

Data Protection Does Not Arise Automatically Either

Storing data on infrastructure under one’s own control can provide additional control over storage locations and access.
However, this does not automatically resolve all data protection questions.

Even with Self-Hosting, the following can be involved, for example:

• data center operators
• Internet providers
• backup service providers
• DNS providers
• external mail services
• certificate authorities
• external support providers

In addition, one’s own access rights, logging, retention periods, and security measures must be designed appropriately.
Self-Hosting changes the responsibility structure.
It does not eliminate it.

Dependencies Do Not Disappear

A self-hosted application can still depend on:

• the software project
• libraries
• operating systems
• hardware
• package sources
• external APIs
• DNS
• certificates
• Internet access
• documentation
• individual people with specialized knowledge

Self-Hosting therefore reduces certain provider dependencies, but can increase other dependencies.
A SaaS dependency can, for example, become a strong dependency on a single administrator.
That too is part of the system perspective.

Self-Hosting and Digital Sovereignty

Self-Hosting can be a tool for Digital Sovereignty.

It can, for example, enable:

own control over data
own version decisions
direct access to configuration
own integrations
more independent migration

But Self-Hosting is not identical to Digital Sovereignty.
A self-operated system can be so complex, poorly documented, or difficult to migrate that there are hardly any real options for action left.
Conversely, an external service with complete data export, open interfaces, and a well-tested exit strategy can provide considerable freedom of action.
The more important question is therefore:

What real options for action does this operating model create for us?

Complexity Matters

The operational effort of a self-hosted system depends heavily on its architecture.

A small service with:

one process
one configuration file
one database
one documented backup procedure

can be relatively easy to manage.

Another system may require:

container orchestration
multiple databases
message brokers
distributed storage
service mesh
external identity services
numerous background services

Both systems can be self-hosted.
Their actual operational effort differs considerably.
The decision to Self-Host should therefore not ask only whether software can technically be operated independently.

It should ask:

Can we understand and reliably operate this concrete system over the long term?

Small Can Be an Advantage

A smaller system does not automatically have better technical properties.

But it can be easier:

• to understand completely
• to document
• to back up
• to restore
• to update
• to migrate
• to examine for dependencies
• to diagnose in the event of a failure

Low complexity can therefore itself become an operational advantage.
This is particularly relevant when a service is intended to be operated for many years with limited personnel resources.

Self-Hosting Needs Information About System State

Anyone operating a service themselves must be able to determine whether it is functioning.

This can include, for example:

service status
error logs
memory usage
disk space
response times
error rates
backup status
certificate expiration dates

Without suitable Observability, a problem may not become known until users notice it.
Self-Hosting therefore means more than control over a service.
It also requires sufficient information about its state.

Self-Hosting Needs an Exit Strategy

A self-hosted solution may also have to be replaced eventually.

For example, because:

• the project is discontinued
• security updates are no longer available
• requirements change
• the system has become too complex
• a better alternative emerges
• necessary expertise is lost

Therefore the question:

“How do we get in here?”

is only half of a system decision.

The second is:

“How do we get out again?”

Even with Self-Hosting, Open Data Formats, documented interfaces, reproducible configurations, and tested migrations can significantly improve future options for action.

When Self-Hosting Can Make Sense

Self-Hosting can be particularly interesting when, for example:

• special control over data is required
• a service needs extensive customization
• external providers do not meet certain requirements
• existing systems need to be integrated directly
• long-term provider dependencies are to be avoided
• operation and architecture can be managed with reasonable effort

These conditions are not a general checklist.
Depending on the system, other reasons may be decisive.

When an External Service Can Make More Sense

An external service can be the better solution when, for example:

• the function has little strategic importance
• operating it oneself would require disproportionate effort
• specialized operational knowledge is lacking
• high availability requirements can be met better externally
• good export and migration options are available
• the existing provider dependency is acceptable

Digital Sovereignty does not require taking on every possible task oneself.
Above all, it requires being able to consciously assess dependencies and consequences.

Why Self-Hosting Has Practical Effects

• More control means more responsibility: Operation and maintenance become part of one’s own responsibilities.
• Infrastructure can still be rented: Self-Hosting does not require owning hardware.
• Updates become an ongoing task: A successful installation is not yet an operating concept.
• Backups must be restorable: Backup files alone are not enough.
• Security and data protection do not arise automatically: They depend on architecture and operation.
• Dependencies are shifted: SaaS dependencies can be replaced by infrastructure, software, or knowledge dependencies.
• Complexity affects manageability: Technically possible Self-Hosting is not necessarily practically sensible.
• Exit capability remains relevant: Self-operated software must also remain replaceable later.
• Self-Hosting can support Digital Sovereignty: It is a tool for it, but not an end in itself.

Typical Example

An organization needs an internal documentation service.

Option A is a SaaS offering.
It costs little, is fully operated by the provider, and requires practically no administration of its own.
However, the data can only be exported incompletely, and several important functions are accessible exclusively through proprietary interfaces.

Option B is a self-hosted Open Source application.
It can be exported completely and has documented interfaces.

Operation requires:

approximately one hour of maintenance per month

Backups are created automatically and regularly test-restored.
Updates can first be checked on a test instance.
For this organization, Option B can create additional digital agency.
For another organization without the corresponding operational expertise, however, the same solution could create greater dependency and higher risk than the SaaS offering.
The software alone therefore does not determine which model provides greater sovereignty.
What matters is the entire system, including the available capabilities and resources.

Distinction

• Self-Hosting refers to operating a digital service under one’s own technical and organizational responsibility.
• Software as a Service (SaaS) refers to a model in which an application is operated and provided as a service by an external provider.
• Digital Sovereignty describes the ability to make autonomous decisions about digital systems and their dependencies and to remain capable of acting when conditions change. Self-Hosting can support this ability.
• Open Source describes, among other things, the rights to use, study, modify, and redistribute software according to its license. Open Source software can be self-hosted, but does not have to be.
• Resilience describes the ability of a system to maintain, restore, or adaptively continue essential functions under disruptions and changes.
• Observability makes it possible to examine the state and behavior of a system from available information and is an important basis for reliable self-operation.

Further Reading

Related Concepts

→ Digital Sovereignty
→ System Architecture
→ System Integration
→ Observability
→ Resilience
→ Legacy System
→ Open Data Format