Self-hosting means running a piece of software on infrastructure you control, such as your own server or cloud account, rather than using the vendor's hosted service.
Self-hosted versus hosted
| Self-hosted | Hosted | |
|---|---|---|
| Data location | Your servers | Vendor's servers |
| Upgrades | You run them | Vendor runs them |
| Uptime | Your job | Vendor's job |
| Cost | Infrastructure and your time | Subscription |
| Customization | Full, if open source | Limited to settings |
Self-hosting is common with open-source software, since you can inspect and change the code you run.
Reasons to self-host
- Data must stay in your environment for policy or compliance.
- You want no per-seat or per-channel limits.
- You want to modify the software.
Reasons not to
- You do not want to manage backups, security patches, and monitoring.
- You need someone else to be accountable for uptime.
An example
A research lab keeps all social account tokens inside its own cloud account for policy reasons. It runs the scheduler with Docker Compose on a small VM and backs up the database nightly.
Why it matters for AI-agent publishing
Your social tokens and your agents' drafts are sensitive. Self-hosting keeps them under your control.
SocialHandoff is open source under AGPL-3.0 and free to self-host with no limits. Run it with Docker Compose, an all-in-one image, or ./run.sh locally. Tokens are encrypted at rest and it runs as a non-root user. A hosted version is available if you prefer. See the self-hosting guide and pricing.