简体中文
English
Website review
This review may include AI-generated content and is not individually verified. Domain, certificate and other facts come from the observed data on this page.
What is GoToSocial?
GoToSocial is a self-hosted, lightweight social media server that speaks ActivityPub, the protocol behind Mastodon and the wider Fediverse. It is aimed at people who want to run a small instance for themselves, a group, or a community without a large server footprint. The documentation describes it as "backend-first": the server handles federation, storage, and moderation, while you use a separate client app to read and post. Because it implements the Mastodon API, many existing Mastodon-compatible apps can connect to it.
GoToSocial Documentation
H3 What it does well
- Federation with control. It supports multiple federation modes, so you can run open, allowlist-based, or more restricted setups.
- Post visibility and replies. Granular visibility settings and reply controls let you decide who can see and who can respond.
- Local-only posting. You can publish posts that stay on your instance rather than federating outward.
- Safety and account features. Safety tools, OIDC integration, and a backend-first design are listed features.
- Easy hosting. The docs emphasize running it on modest hardware, including BSD systems, Docker, binary releases, and source installs.
H3 Who it suits
A practical reader is someone who already has a domain and a small VPS, wants a personal or club instance, and prefers a lean service over a full Mastodon deployment. If you need a large public instance with heavy web UI customization out of the box, a more traditional server may fit better. If you want to tinker with federation rules, local-only posts, or run on low-power hardware, GoToSocial is a strong candidate.
H3 A useful next step
Decide your federation mode before installing. If you want a quiet personal space, start with a restricted mode and test local-only posting first. If you want to join the wider Fediverse, begin with a small allowlist or open mode and watch moderation tools closely. Then pick an install path from the documentation's supported platforms: bare metal, container, or a packaged release.
For broader context on the network it joins, see Mastodon and ActivityPub.
How do I install GoToSocial on my own server?
GoToSocial is self-hosted server software for federated social networking (ActivityPub). Installing it on your own server means running the GoToSocial daemon yourself, then connecting a client app to it. The documentation lays out several installation paths, so the main decision is which one matches your server skills and update habits.
Choose an installation method
| Method | Best for | Trade-off |
|---|---|---|
Binary release .tar.gz |
Simple, direct installs on a supported 64-bit BSD or Linux system | You manage the service, updates and dependencies yourself |
| Docker | Most self-hosters who want an isolated, repeatable setup | Requires Docker knowledge and container maintenance |
| From source | People who want to modify or track the code | Needs a build toolchain and more effort |
| Third-party packaging | Users of a distro or platform with existing packages | Package may lag behind releases |
Basic steps
- Check the supported platforms first — the docs list 64-bit BSDs and 32-bit OpenBSD, among others. Confirm your OS and architecture are covered.
- Pick a release channel: stable releases for reliability, snapshots if you want newer changes and accept more risk.
- Install using your chosen method (binary, Docker, source or package).
- Configure the instance: general settings, database, instance/accounts, media storage, statuses, TLS, and optionally OIDC, email/SMTP and syslog.
- Put a reverse proxy in front — the docs cover NGINX, Apache HTTP Server and Caddy 2, including WebSocket handling.
- Create your user account, then connect a client via the Mastodon-compatible API.
Before you commit
Read the deployment considerations and the "Known Issues" page, and decide how you will handle backups, database maintenance and upgrades. If you are unsure between binary and Docker, Docker is usually the easier path to reproduce and update; the binary route is leaner if you prefer to manage the service directly.
For the authoritative, current instructions, start at the official documentation: GoToSocial Documentation.
How does GoToSocial's Mastodon API compatibility affect which apps I can use?
GoToSocial implements the Mastodon client API, so most third-party Mastodon apps can talk to it without modification. The documentation lists "Mastodon API compatibility" as a headline feature, meaning app choice is not limited to a GoToSocial-specific client.
H3 What that means in practice
- You can generally point an existing Mastodon app at your GoToSocial instance and log in normally.
- App features built on standard endpoints — timelines, posting, notifications, search, follow requests — should work.
- Features that depend on server-side extras (some admin tools, certain moderation views, or app-specific push setups) may behave differently or be unavailable, since compatibility covers the API surface, not every Mastodon server behaviour.
H3 Choosing an app If you mainly read, post and manage follows, a mainstream Mastodon client is the low-effort choice. If you rely on GoToSocial-specific behaviours — granular post visibility, reply controls, local-only posting — check whether your app exposes them, because a compatible client may still not surface non-Mastodon options.
H3 Practical next step Log in with one app you already know, then test the two or three things you actually depend on (threaded replies, media uploads, notifications). If something is missing, try another client before assuming the instance is at fault.
Useful references: the project's own documentation at GoToSocial Documentation and the wider client ecosystem listed by Mastodon.
What are the differences between the available federation modes in GoToSocial?
GoToSocial's federation modes control how much of the wider Fediverse your instance can see and interact with. Choosing one is mostly a trade-off between openness, resource use, and how much moderation you want to take on.
The modes at a glance
| Mode | What it does | Best for |
|---|---|---|
| Open | Federates with any instance by default; blocks only what you explicitly block | Public or community instances that want maximum reach |
| Allowlist | Federates only with instances you approve | Private, family, or topic-focused instances |
| Blocklist | Federates broadly but rejects instances you list | Instances that want openness with targeted exclusions |
In practice, the key distinction is default behaviour: allowlist mode starts closed and opens up per instance, while blocklist mode starts open and closes down per instance. Open mode is effectively blocklist mode with nothing blocked yet.
How to choose
Ask what happens when a new instance appears that you have never heard of:
- If you want it to be reachable immediately, use blocklist or open.
- If you want to review it first, use allowlist.
The cost of allowlist mode is ongoing admin work: every new instance your users want to follow must be approved. The cost of blocklist mode is that unwanted content can arrive before you act, so moderation has to be timely. Open mode is the least work but leaves you most exposed to spam and abuse.
GoToSocial also documents related admin controls such as domain blocks, domain limits, and domain permission subscriptions, which let you automate parts of either approach rather than approving or blocking domains one by one. If you expect to run an allowlist, permission subscriptions are worth setting up early so you are not doing everything manually.
A concrete scenario
A small instance for a research group might run allowlist mode and subscribe to a curated domain list, so members can follow colleagues at known institutions without the admin vetting each domain by hand. A public instance with an active moderation team would more likely run blocklist mode and rely on shared blocklists, accepting that some unwanted traffic will arrive and be removed after the fact.
Start by reading the federation modes section of the admin documentation at GoToSocial Documentation, then decide based on how much ongoing moderation capacity you actually have, not on how open you would like to be in theory.
How can I import my posts and followers from another Mastodon instance?
GoToSocial's documentation covers migration, but the official docs are mainly a technical reference. For most people moving from an existing Mastodon account, the practical path is Mastodon's own import/export tools on the old server, then re-following people on the new GoToSocial account.
What you can usually move
- Your posts: export an archive from your old Mastodon instance, then import it into GoToSocial. The docs list "Importing posts from previous instances" as a user-guide topic, so this is a supported workflow rather than a manual copy-paste.
- Your followers: you generally cannot move followers directly between servers. Mastodon's "move followers" feature requires the destination account to be reachable and to cooperate with the old server's redirect. GoToSocial's docs do not present a simple follower-transfer button, so expect to rebuild your follower list by posting your new handle.
- Your follows: export your following list from Mastodon and re-follow from your GoToSocial account.
- Your profile data: display name, bio, avatar and header can be set again manually; there is no universal one-click profile transfer.
A practical sequence
- On your old Mastodon account, request a data export (archive of posts, follows, lists, bookmarks).
- Set up your GoToSocial account and confirm you can post and be found.
- Import your posts into GoToSocial using its import tooling.
- Re-follow accounts using your exported following list.
- Announce your new handle from both accounts so people can find you. If your old server supports account migration, use it to point your old profile at the new one.
Trade-offs and caveats
Importing posts is not the same as moving an account. Timestamps, boosts, replies and media may not survive perfectly, and follower counts will not transfer automatically. If keeping your existing followers matters more than running your own server, staying on your current instance or using Mastodon's official move feature is usually less disruptive. If control over your data and hosting is the priority, GoToSocial is a reasonable destination and rebuilding followers is the price.
For installation and configuration details, see GoToSocial Documentation. For the export side, use your old instance's settings, or consult Mastodon Documentation.
What are the known issues and limitations of GoToSocial?
GoToSocial's documentation treats known issues as a standing section rather than a one-off changelog, which is a useful signal: this is software under active development, and you should expect some rough edges to persist between releases. The documentation also lists supported platforms and installation paths, so the practical limitations depend heavily on how you deploy it.
Where limitations show up in practice
- Feature maturity varies. The feature list includes Mastodon API compatibility, granular post visibility, reply controls, local-only posting, federation modes, and OIDC integration. Breadth does not guarantee every feature is finished or stable; check the known issues page for the current state before relying on one.
- Federation is inherently partial. GoToSocial's federation modes and domain controls give you levers, but interoperability with the wider fediverse depends on other servers' behavior as much as on GoToSocial.
- Operational complexity is real. The docs cover reverse proxies (NGINX, Apache, Caddy 2), TLS, caching, tracing, metrics, and SQLite replication. A single-user instance is manageable; a larger one needs someone comfortable with that stack.
- Platform support is narrow. Supported platforms are 64-bit BSDs and 32-bit OpenBSD, plus Docker, binary releases, source builds, and third-party packaging. If you are on Windows or a mainstream Linux distro, you are likely going through Docker or a community package rather than a first-party install.
Choosing between deployment paths
| Path | Best for | Trade-off |
|---|---|---|
| Docker | Most self-hosters wanting a repeatable setup | You inherit container networking and volume management |
| Binary release / source | BSD users and those wanting tight control | You handle updates, TLS, and the reverse proxy yourself |
| Third-party packaging | Users on distros with a maintainer | Update cadence depends on the packager |
A concrete check before committing
Pick the two or three features you actually need — say, local-only posting and OIDC login — and confirm each one's current status in the known issues section rather than the feature list. If a needed feature is listed as incomplete, that is your decision point, not a reason to abandon the project.
For the authoritative and current list, read the known issues page directly at GoToSocial Documentation, and compare against the project's release notes on Codeberg before you migrate an existing account.
Cloudflare
Proton Mail
User reviews (0)