GoToSocial Install Notes

Along with building Akkoma instances (build notes here) and Mastodon instances, I have been playing around with GoToSocial. GoToSocial is a project I am watching because it is easy to install, doesn’t use much in terms of system resources and doesn’t require PostgreSQL (though it is an option) as it can use SQLite. The project is alpha right now, but it is quite usable. There is no front-end UI for anything except modifying your profile and displaying your profile to visitors – which is fine since there are great clients out there.

The installation instructions work great, they are generic enough to allow people to have flexibility to their installs – for instance using nginx, Apache or Caddy 2 to be a reverse proxy.

These are my notes from installing GoToSocial a few times with very specific build specs. Specifically, I’m using Ubuntu as the OS, nginx as the reverse proxy and Cloudflare as a CDN. The Cloudflare part only changes how I do SSL certs, if you’re not using Cloudflare, the certbot instructions in the official docs work great.

nginx

Instead of installing GoToSocial first, I start out with nginx as it’ll make testing the instance easier.

apt install nginx

Create a configuration file for your host /etc/nginx/sites-available/gotosocial.conf

I incorporated the changes suggested by the official documenation to have nginx serve static assets. Although GoToSocial will gladly serve static assets, it’s more efficient (and faster) if nginx does it. There are two static assets paths: /assets and /filesystem. /assets has assets for the web UI. /filesystem has post attachments (and avatars).

You’ll need to know the location of these two paths on the OS filesystem for the nginx configuration. If you’re installing based on the official documentation then the nginx configuration below will work for serving these static assets without changes to the settings for the two paths.

If you have changed where you installed GoToSocial, the location of these two paths are in your installation directory:

  • /assets is located in /INSTALL_DIR/web/assets/
  • /filesystem is located in /INSTALL_DIR/storage/

Change YOUR.HOST.TLD to the hostname for your instance. Change YOUR_SSL_CERT and YOUR_SSL_PRIVATE_KEY to point to the files for the respective things.

2/16/2023: The section for the location /fileserver/ is commented out because if that is active in nginx, gotosocial does not refetch media that has been purged when the media retention purge job runs. I had my instance set to purge media after two days. What I found was that after two days, people that I follow or have followed me more than two days ago were missing their avatars and backgrounds as they had been removed from the filesystem. Because nginx is proxying the media connection, gotosocial doesn’t know to go refetch that media.

4/14/2024: The documentation on the GoToSocial site has a fix for the /fileserver/ issue. I have updated the nginx configuration that I am using with that fix. I have also updated the configuration with some tweaks for performance (proxy buffer stuff, proxy http version, tcp_nodelay and gzip stuff). I’ve also created an upstream named backend to simplify the location / and @fileserver.

upstream backend {
    server 127.0.0.1:8080;
}

server {
  server_name YOUR.HOST.TLD;
  location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering on;
    proxy_buffer_size 2k;
    proxy_buffers 64 4k;
    proxy_http_version 1.1;
    tcp_nodelay on;
  }

  location /assets/ {
    alias /gotosocial/web/assets/;
    autoindex off;
    expires 7d;
    add_header Cache-Control "public";
  }

location @fileserver {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering on;
    proxy_buffer_size 2k;
    proxy_buffers 64 4k;
    proxy_http_version 1.1;
    tcp_nodelay on;
}

location /fileserver/ {
    alias /gotosocial/storage/;
    autoindex off;
    expires 1w;
    add_header Cache-Control "private, immutable";
    try_files $uri @fileserver;
}
  client_max_body_size 40M;

  listen [::]:443 ssl ipv6only=on http2;
  listen 443 ssl http2;

  ssl_certificate /etc/ssl/certs/YOUR_SSL_CERT;
  ssl_certificate_key /etc/ssl/private/YOUR_SSL_PRIVATE_KEY;

  access_log /var/log/nginx/access.log combined;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript
 image/svg+xml image/x-icon;

}

server {
  if ($host = YOUR.HOST.TLD) {
      return 301 https://$host$request_uri;
  }

  listen 80;
  listen [::]:80;
  server_name YOUR.HOST.TLD;
    return 404;
}

Enable the nginx configuration:

ln -s /etc/nginx/sites-available/gotosocial.conf /etc/nginx/sites-enabled/gotosocial.conf

Check that all is good:

nginx -t

If it’s good, restart nginx:

systemctl restart nginx

GoToSocial

Now install GoToSocial based on the official install documentation. The instructions are super clear, concise and will get GoToSocial installed without hassle.

If you’re running GoToSocial as a single-user instance, don’t forget to flip this setting to false:

accounts-registration-open: false

When you get to the “[Optional] Enable the systemd service”, there’s one minor tweak. Since we are using a reverse proxy, you’ll want to uncomment this line in /etc/systemd/system/gotosocial.service.

AmbientCapabilities=CAP_NET_BIND_SERVICE

Admin and Custom Emojis

The admin panel that you can be found at https://YOUR.HOST.TLD/admin.

Make sure you have your user promoted as an admin to be able to use the admin interface.

./gotosocial --config-path ./config.yaml admin account promote --username YOUR_USERNAME

The admin interface provided a couple of things that I couldn’t do via the command-line tool or configuration file:

  • Change the name of my instance.
  • Add a description of my instance.
  • Add a contact for my instance.
  • Add custom emojis (this is important)
  • Block naughty instances.
  • Manually purge remote media.

That’s it!