Moving docs to tootsuite/documentation (#1550)

7 files changed, 7 insertions, 625 deletions

diff --git a/docs/Running-Mastodon/Administration-guide.md b/docs/Running-Mastodon/Administration-guide.md
index 8bcfe7c9e..e7571be3a 100644
--- a/docs/Running-Mastodon/Administration-guide.md
+++ b/docs/Running-Mastodon/Administration-guide.md
@@ -1,45 +1 @@
-Administration guide
-====================
-
-So, you have a working Mastodon instance... now what?
-
-## Turning into an admin
-
-The following rake task:
-
-    RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=alice
-
-Would turn the local user "alice" into an admin.
-
-## Administration web interface
-
-A user that is designated as `admin = TRUE` in the database is able to access a suite of administration tools:
-
-* View, edit, silence, or suspend users - https://yourmastodon.instance/admin/accounts
-* View PubSubHubbub subscriptions - https://yourmastodon.instance/admin/pubsubhubbub
-* View domain blocks - https://yourmastodon.instance/admin/domain_blocks
-* Sidekiq dashboard - https://yourmastodon.instance/sidekiq
-* PGHero dashboard for PostgreSQL - https://yourmastodon.instance/pghero
-* Edit site settings - https://yourmastodon.instance/admin/settings
-
-## Site settings
-
-Your site settings are stored in the `settings` database table, and editable through the admin interface at https://yourmastodon.instance/admin/settings.
-
-You are able to set the following settings:
-
-- Site title
-- Contact username
-- Contact email
-- Site description
-- Site extended description
-
-You may wish to use the extended description (shown at https://yourmastodon.instance/about/more ) to display content guidelines or a user agreement (see https://mastodon.social/about/more for an example).
-
-## Confirming Users Manually
-
-The following rake task:
-
-    RAILS_ENV=production bundle exec rails mastodon:confirm_email USER_EMAIL=alice@alice.com
-
-Will confirm a user manually, in case they don't have access to their confirmation email for whatever reason.
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Administration-guide.md)
diff --git a/docs/Running-Mastodon/Development-guide.md b/docs/Running-Mastodon/Development-guide.md
index 27efa346e..10ed64087 100644
--- a/docs/Running-Mastodon/Development-guide.md
+++ b/docs/Running-Mastodon/Development-guide.md
@@ -1,50 +1 @@
-Development guide
-=================
-
-**Don't use Docker to do development**. It's a quick way to get Mastodon running in production, it's **really really inconvenient for development**. Normally in Rails development environment you get hot reloading of backend code and on-the-fly compilation of assets like JS and CSS, but you lose those benefits by compiling a Docker image. If you want to contribute to Mastodon, it is worth it to simply set up a proper development environment.
-
-In fact, all you need is described in the [production guide](Production-guide.md), **with the following exceptions**. You **don't** need:
-
-- Nginx
-- SystemD
-- An `.env.production` file. If you need to set any environment variables, you can use an `.env` file
-- To prefix any commands with `RAILS_ENV=production` since the default environment is "development" anyway
-- Any cronjobs
-
-The command to install project dependencies does not require any flags, i.e. simply
-
-    bundle install
-
-By default the development environment wants to connect to a `mastodon_development` database on localhost using your user/ident to login to Postgres (i.e. not a md5 password)
-
-You can run Mastodon with:
-
-    rails s
-
-And open `http://localhost:3000` in your browser. Background jobs run inline (aka synchronously) in the development environment, so you don't need to run a Sidekiq process. 
-
-By default, your development environment will have an admin account created for you to use - the email address will be `admin@YOURDOMAIN` (e.g. admin@localhost:3000) and the password will be `mastodonadmin`.
-
-You can run tests with:
-
-    rspec
-
-You can check localization status with:
-
-    i18n-tasks health
-
-You can check code quality with:
-
-    rubocop
-
-## Development tips
-
-You can use a localhost->world tunneling service like ngrok if you want to test federation, **however** that should not be your primary mode of operation. If you want to have a permanently federating server, set up a proper instance on a VPS with a domain name, and simply keep it up to date with your own fork of the project while doing development on localhost.
-
-Ngrok and similar services give you a random domain on each start up. This is good enough to test how the code you're working on handles real-world situations. But as soon as your domain changes, for everybody else concerned you're a different instance than before.
-
-Generally, federation bits are tricky to work on for exactly this reason - it's hard to test. And when you are testing with a disposable instance you are polluting the databases of the real servers you're testing against, usually not a big deal but can be annoying. The way I have handled this so far was thus: I have used ngrok for one session, and recorded the exchanges from its web interface to create fixtures and test suites. From then on I've been working with those rather than live servers.
-
-I advise to study the existing code and the RFCs before trying to implement any federation-related changes. It's not *that* difficult, but I think "here be dragons" applies because it's easy to break.
-
-If your development environment is running remotely (e.g. on a VPS or virtual machine), setting the `REMOTE_DEV` environment variable will swap your instance from using "letter opener" (which launches a local browser) to "letter opener web" (which collects emails and displays them at /letter_opener ).
\ No newline at end of file
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Development-guide.md)
diff --git a/docs/Running-Mastodon/Heroku-guide.md b/docs/Running-Mastodon/Heroku-guide.md
index 4978a20ac..aa5abc1f5 100644
--- a/docs/Running-Mastodon/Heroku-guide.md
+++ b/docs/Running-Mastodon/Heroku-guide.md
@@ -1,86 +1 @@
-Heroku guide
-============
-
-[![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://dashboard.heroku.com/new?button-url=https://github.com/tootsuite/mastodon&template=https://github.com/tootsuite/mastodon)
-
-Mastodon can be run on a free [Heroku](https://heroku.com) app. It should be
-noted this has limited testing and could have unpredictable results.
-
-## Basic setup
-
-Click the button above to start creating a Heroku app with the Mastodon repo as
-the source. This tells Heroku to use the `app.json` file which does things like
-prompt for config variables, set up the right buildpacks, run a postdeploy task,
-and add the appropriate addons.
-
-If you don't use the deploy button and app.json approach, you will need to do
-some of that manually.
-
-## Domain names and SSL
-
-You can add your domain name to the Heroku app's setting, and then also use
-Heroku's (free) auto renewal program for Lets Encrypt certificates, by
-requesting a cert from the settings screen. You'll have to point your hostname
-DNS at Heroku using the values heroku gives you on this screen, using whatever
-method is appropriate for your DNS setup.
-
-You should set the Heroku config vars of `LOCAL_DOMAIN` to your hostname, and
-`LOCAL_HTTPS` to "true" as well.
-
-## Email
-
-Consider using [Mailgun](https://mailgun.com) or similar, who offer free plans
-that should suit your interests. Look in `production.rb` to see which config
-variables need to be set on Heroku for outgoing email to work.
-
-## File storage
-
-You will want Amazon S3 for file storage. The only exception is for development
-purposes, where you may not care if files are not saved. Follow a guide online
-for creating a free Amazon S3 bucket and Access Key, then enter the details.
-
-If you deploy from the web, the format for all the S3 bits use Paperclip conventions:
-
-S3 Bucket is just the name of the bucket, e.g. `bucketname` not the full ARN.
-
-S3 Region is the AWS code for the region e.g. `ap-northeast-1` not the name of the city displayed on the AWS Dashboard.
-
-To protect the privacy of the users of the your instance, you should have permissons on the your S3 bucket set to no-read and no-write for the public and non-application-specific AWS users, with only one authorized IAM user or group set up to be able to upload or display content. This is an example of an IAM policy used for the S3 bucket used Mastadon instance hentai.loan:
-
-    {
-        "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Effect": "Allow",
-                "Action": [
-                    "s3:ListAllMyBuckets"
-                ],
-                "Resource": [
-                    "arn:aws:s3:::*"
-                ]
-            },
-            {
-                "Effect": "Allow",
-                "Action": [
-                    "s3:*"
-                ],
-                "Resource": [
-                    "arn:aws:s3:::hentailoan”,
-                    "arn:aws:s3:::hentailoan/*"
-                ]
-            }
-        ]
-    }
-
-
-## Deployment
-
-You can deploy from the Heroku web interface or from the command line. Run:
-
-  `heroku run rails db:migrate`
-
-after you first deploy to set up the first database.
-
-To make yourself an admin, you may need to use the `heroku` CLI application after creating an account online:
-
-  `heroku rake mastodon:make_admin USERNAME=yourUsername`
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Heroku-guide.md)
diff --git a/docs/Running-Mastodon/Production-guide.md b/docs/Running-Mastodon/Production-guide.md
index 49f3e59b2..08649e9ce 100644
--- a/docs/Running-Mastodon/Production-guide.md
+++ b/docs/Running-Mastodon/Production-guide.md
@@ -1,261 +1 @@
-Production guide
-================
-
-## Nginx
-
-Regardless of whether you go with the Docker approach or not, here is an example Nginx server configuration:
-
-```nginx
-map $http_upgrade $connection_upgrade {
-  default upgrade;
-  ''      close;
-}
-
-server {
-  listen 80;
-  listen [::]:80;
-  server_name example.com;
-  return 301 https://$host$request_uri;
-}
-
-server {
-  listen 443 ssl;
-  server_name example.com;
-
-  ssl_protocols TLSv1.2;
-  ssl_ciphers EECDH+AESGCM:EECDH+AES;
-  ssl_ecdh_curve prime256v1;
-  ssl_prefer_server_ciphers on;
-  ssl_session_cache shared:SSL:10m;
-
-  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
-  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
-
-  keepalive_timeout    70;
-  sendfile             on;
-  client_max_body_size 0;
-
-  root /home/mastodon/live/public;
-
-  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;
-
-
-  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
-
-  location / {
-    try_files $uri @proxy;
-  }
-
-  location @proxy {
-    proxy_set_header Host $host;
-    proxy_set_header X-Real-IP $remote_addr;
-    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    proxy_set_header X-Forwarded-Proto https;
-    proxy_set_header Proxy "";
-    proxy_pass_header Server;
-
-    proxy_pass http://localhost:3000;
-    proxy_buffering off;
-    proxy_redirect off;
-    proxy_http_version 1.1;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-
-    tcp_nodelay on;
-  }
-
-  location /api/v1/streaming {
-    proxy_set_header Host $host;
-    proxy_set_header X-Real-IP $remote_addr;
-    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    proxy_set_header X-Forwarded-Proto https;
-    proxy_set_header Proxy "";
-
-    proxy_pass http://localhost:4000;
-    proxy_buffering off;
-    proxy_redirect off;
-    proxy_http_version 1.1;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection $connection_upgrade;
-
-    tcp_nodelay on;
-  }
-
-  error_page 500 501 502 503 504 /500.html;
-}
-```
-
-## Running in production without Docker
-
-It is recommended to create a special user for mastodon on the server (you could call the user `mastodon`), though remember to disable outside login for it. You should only be able to get into that user through `sudo su - mastodon`.
-
-## General dependencies
-
-    sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs file git curl
-    curl -sL https://deb.nodesource.com/setup_4.x | sudo bash -
-
-    sudo apt-get install nodejs
-
-    sudo npm install -g yarn
-
-## Redis
-
-    sudo apt-get install redis-server redis-tools
-
-## Postgres
-
-    sudo apt-get install postgresql postgresql-contrib
-
-Setup a user and database for Mastodon:
-
-    sudo su - postgres
-    psql
-
-In the prompt:
-
-    CREATE USER mastodon CREATEDB;
-    \q
-
-## Rbenv
-
-It is recommended to use rbenv (exclusively from the `mastodon` user) to install the desired Ruby version. Follow the guides to [install rbenv][1] and [rbenv-build][2] (I recommend checking the [prerequisites][3] for your system on the rbenv-build project and installing them beforehand, obviously outside the unprivileged `mastodon` user)
-
-[1]: https://github.com/rbenv/rbenv#installation
-[2]: https://github.com/rbenv/ruby-build#installation
-[3]: https://github.com/rbenv/ruby-build/wiki#suggested-build-environment
-
-Then once `rbenv` is ready, run `rbenv install 2.4.1` to install the Ruby version for Mastodon.
-
-## Git
-
-You need the `git-core` package installed on your system. If it is so, from the `mastodon` user:
-
-    cd ~
-    git clone https://github.com/tootsuite/mastodon.git live
-    cd live
-
-Then you can proceed to install project dependencies:
-
-    gem install bundler
-    bundle install --deployment --without development test
-    yarn install
-
-## Configuration
-
-Then you have to configure your instance:
-
-    cp .env.production.sample .env.production
-    nano .env.production
-
-Fill in the important data, like host/port of the redis database, host/port/username/password of the postgres database, your domain name, SMTP details (e.g. from Mailgun or equivalent transactional e-mail service, many have free tiers), whether you intend to use SSL, etc. If you need to generate secrets, you can use:
-
-    rake secret
-
-To get a random string. If you are setting up on one single server (most likely), then `REDIS_HOST` is localhost and `DB_HOST` is `/var/run/postgresql`, `DB_USER` is `mastodon` and `DB_NAME` is `mastodon_production` while `DB_PASS` is empty because this setup will use the ident authentication method (system user "mastodon" maps to postgres user "mastodon").
-
-## Setup
-
-And setup the database for the first time, this will create the tables and basic data:
-
-    RAILS_ENV=production bundle exec rails db:setup
-
-Finally, pre-compile all CSS and JavaScript files:
-
-    RAILS_ENV=production bundle exec rails assets:precompile
-
-## Systemd
-
-Example systemd configuration for the web workers, to be placed in `/etc/systemd/system/mastodon-web.service`:
-
-```systemd
-[Unit]
-Description=mastodon-web
-After=network.target
-
-[Service]
-Type=simple
-User=mastodon
-WorkingDirectory=/home/mastodon/live
-Environment="RAILS_ENV=production"
-Environment="PORT=3000"
-ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
-TimeoutSec=15
-Restart=always
-
-[Install]
-WantedBy=multi-user.target
-```
-
-Example systemd configuration for the background workers, to be placed in `/etc/systemd/system/mastodon-sidekiq.service`:
-
-```systemd
-[Unit]
-Description=mastodon-sidekiq
-After=network.target
-
-[Service]
-Type=simple
-User=mastodon
-WorkingDirectory=/home/mastodon/live
-Environment="RAILS_ENV=production"
-Environment="DB_POOL=5"
-ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push
-TimeoutSec=15
-Restart=always
-
-[Install]
-WantedBy=multi-user.target
-```
-
-Example systemd configuration file for the streaming API, to be placed in `/etc/systemd/system/mastodon-streaming.service`:
-
-```systemd
-[Unit]
-Description=mastodon-streaming
-After=network.target
-
-[Service]
-Type=simple
-User=mastodon
-WorkingDirectory=/home/mastodon/live
-Environment="NODE_ENV=production"
-Environment="PORT=4000"
-ExecStart=/usr/bin/npm run start
-TimeoutSec=15
-Restart=always
-
-[Install]
-WantedBy=multi-user.target
-```
-
-This allows you to `sudo systemctl enable /etc/systemd/system/mastodon-*.service` and `sudo systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service` to get things going.
-
-## Cronjobs
-
-I recommend creating a couple cronjobs for the following tasks:
-
-- `RAILS_ENV=production bundle exec rake mastodon:media:clear`
-- `RAILS_ENV=production bundle exec rake mastodon:push:refresh`
-- `RAILS_ENV=production bundle exec rake mastodon:feeds:clear`
-
-You may want to run `which bundle` first and copypaste that full path instead of simply `bundle` in the above commands because cronjobs usually don't have all the paths set. The time and intervals of when to run these jobs are up to you, but once every day should be enough for all.
-
-You can edit the cronjob file for the `mastodon` user by running `sudo crontab -e -u mastodon` (outside of the mastodon user).
-
-## Things to look out for when upgrading Mastodon
-
-You can upgrade Mastodon with a `git pull` from the repository directory. You may need to run:
-
-- `RAILS_ENV=production bundle exec rails db:migrate`
-- `RAILS_ENV=production bundle exec rails assets:precompile`
-
-Depending on which files changed, e.g. if anything in the `/db/` or `/app/assets` directory changed, respectively. Also, Mastodon runs in memory, so you need to restart it before you see any changes. If you're using systemd, that would be:
-
-    sudo systemctl restart mastodon-*.service
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md)
diff --git a/docs/Running-Mastodon/Scalingo-guide.md b/docs/Running-Mastodon/Scalingo-guide.md
index 9329f753e..8c986f750 100644
--- a/docs/Running-Mastodon/Scalingo-guide.md
+++ b/docs/Running-Mastodon/Scalingo-guide.md
@@ -1,13 +1 @@
-Scalingo guide
-==============
-
-[![Deploy on Scalingo](https://cdn.scalingo.com/deploy/button.svg)](https://my.scalingo.com/deploy?source=https://github.com/tootsuite/mastodon#master)
-
-1. Click the above button.
-2. Fill in the options requested.
-  * You can use a .scalingo.io domain, which will be simple to set up, or you can use a custom domain.
-  * You will want Amazon S3 for file storage. The only exception is for development purposes, where you may not care if files are not saved. Follow a guide online for creating a free Amazon S3 bucket and Access Key, then enter the details.
-  * If you want your Mastodon to be able to send emails, configure SMTP settings here (or later). Consider using [Mailgun](https://mailgun.com) or similar, who offer free plans that should suit your interests.
-3. Deploy! The app should be set up, with a working web interface and database. You can change settings and manage versions from the Scalingo dashboard.
-
-To make yourself an admin, you can use the `scalingo` CLI: `scalingo run -e USERNAME=yourusername rails mastodon:make_admin`.
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Scalingo-guide.md)
diff --git a/docs/Running-Mastodon/Tuning.md b/docs/Running-Mastodon/Tuning.md
index c4acb9927..41fa93ef3 100644
--- a/docs/Running-Mastodon/Tuning.md
+++ b/docs/Running-Mastodon/Tuning.md
@@ -1,104 +1 @@
-Tuning Mastodon
-===============
-
-Mastodon has three types of processes:
-
-- web
-- streaming API
-- background processing
-
-By default, the web type spawns two worker processes with 5 threads each, the streaming API is a single thread/process with 10 database pool connections, and background processing spawns one process with 5 threads.
-
-### Web
-
-The web process serves short-lived HTTP requests for most of the application. The following environment variables control it:
-
-- `WEB_CONCURRENCY` controls the number of worker processes
-- `MAX_THREADS` controls the number of threads per process
-
-The default is 2 workers with 5 threads each. Threads share the memory of their parent process. Different processes allocate their own memory each. Threads in Ruby are not native threads, so it's more or less: threads equal concurrency, processes equal parallelism. A larger number of threads maxes out your CPU first, a larger number of processes maxes out your RAM first.
-
-These values affect how many HTTP requests can be served at the same time. When not enough threads are available, requests are queued until they can be answered.
-
-For a single-user instance, 1 process with 5 threads should be more than enough.
-
-### Streaming API
-
-The streaming API handles long-lived HTTP and WebSockets connections, through which clients receive real-time updates. It is a single-threaded process. By default it has a database connection pool of 10, which means 10 different database queries can run *at the same time*. The database is not heavily used in the streaming API, only for initial authentication of the request, and for some special receiver-specific filter queries when receiving new messages. At the time of writing this value cannot be reconfigured, but mostly doesn't need to.
-
-If you need to scale up the streaming API, spawn more separate processes on different ports (e.g. 4000, 4001, 4003, etc) and load-balance between them with nginx.
-
-### Background processing
-
-Many tasks in Mastodon are delegated to background processing to ensure the HTTP requests are fast, and to prevent HTTP request aborts from affecting the execution of those tasks. Sidekiq is a single process, with a configurable numbero of threads. By default, it is 5. That means, 5 different jobs can be executed at the same time. Others will be queued until they can be processed.
-
-While the amount of threads in the web process affects the responsiveness of the Mastodon instance to the end-user, the amount of threads allocated to background processing affects how quickly posts can be delivered from the author to anyone else, how soon e-mails are sent out, etc.
-
-The amount of threads is not controlled by an environment variable in this case, but a command line argument in the invocation of Sidekiq:
-
-    bundle exec sidekiq -c 15 -q default -q mailers -q push
-
-Would start the sidekiq process with 15 threads. Please mind that each threads needs to be able to connect to the database, which means that the database pool needs to be large enough to support all the threads. The database pool size is controlled with the `DB_POOL` environment variable, and defaults to the value of `MAX_THREADS` (therefore, is 5 by default).
-
-You might notice that the above command specifies three queues to be processed:
-
-- "default" contains most tasks such as delivering messages to followers and processing incoming notifications from other instances
-- "mailers" contains tasks that send e-mails
-- "push" contains tasks that deliver messages to other instances
-
-If you wish, you could start three different processes for each queue, to ensure that even when there is a lot of tasks of one type, important tasks of other types still get executed in a timely manner.
-
-___
-
-### How to set environment variables
-#### With systemd
-
-In the `.service` file:
-
-```systemd
-...
-Environment="WEB_CONCURRENCY=1"
-Environment="MAX_THREADS=5"
-ExecStart="..."
-...
-```
-
-Don't forget to `sudo systemctl daemon-reload` before restarting the services so that the changes would take effect!
-
-#### With docker-compose
-
-Edit `docker-compose.yml`:
-
-```yml
-...
-  web:
-    restart: always
-    build: .
-    env_file: .env.production
-    environment:
-      - WEB_CONCURRENCY=1
-      - MAX_THREADS=5
-...
-```
-
-Re-create the containers with `docker-compose up -d` for the changes to take effect.
-
-You can also scale the number of containers per "service" (where service is "web", "sidekiq" and "streaming"):
-
-    docker-compose scale web=1 sidekiq=2 streaming=3
-
-Realistically the `docker-compose.yml` file needs to be modified a bit further for the above to work, because by default it wants to bind the web container to host port 3000 and streaming container to host port 4000, of either of which there is only one on the host system. However, if you change:
-
-```yml
-ports:
-  - "3000:3000"
-```
-
-to simply:
-
-```yml
-ports:
-  - "3000"
-```
-
-for each service respectively, Docker will allocate random host ports of the services, allowing multiple containers to run alongside each other. But it will be on you to look up which host ports those are (e.g. with `docker ps`), and they will be different on each container restart.
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Tuning-guide.md)
diff --git a/docs/Running-Mastodon/Vagrant-guide.md b/docs/Running-Mastodon/Vagrant-guide.md
index 83a892408..c5823b09b 100644
--- a/docs/Running-Mastodon/Vagrant-guide.md
+++ b/docs/Running-Mastodon/Vagrant-guide.md
@@ -1,66 +1 @@
-Vagrant guide
-=============
-
-A quick way to get a development environment up and running is with Vagrant. You will need recent versions of [Vagrant](https://www.vagrantup.com/) and [VirtualBox](https://www.virtualbox.org/) installed.
-
-## Basic setup
-
-Install the latest versions of Vagrant and VirtualBox for your operating systems, and then run:
-
-    vagrant plugin install vagrant-hostsupdater
-
-This is optional, but will update your 'hosts' file when you start the virtual machine, allowing you to access the site at http://mastodon.dev (instead of http://localhost:3000).
-
-To create and provision a new virtual machine for Mastodon development:
-
-    git clone git@github.com:tootsuite/mastodon.git
-    cd mastodon
-    vagrant up
-
-**Note:** On Linux hosts, you will need to [enable NFS support](https://www.vagrantup.com/docs/synced-folders/nfs.html).
-
-Running `vagrant up` for the first time will run provisioning, which will:
-
-- Download the Ubuntu 14.04 base image, if there isn't already a copy on your machine
-- Create a new VirtualBox virtual machine from that image
-- Run the provisioning script (located inside the Vagrantfile), which installs the system packages, Ruby gems, and JS modules required for Mastodon
-- Run the startup script
-
-## Starting the server
-
-The Vagrant box will automatically start after provisioning. It can be started in future with `vagrant up` from the mastodon directory.
-
-Once the Ubuntu virtual machine has booted, it will run the startup script, which loads the environment variables from `.env.vagrant` and then runs `rails s -d -b 0.0.0.0`. This will start a Rails server. You can then access your development site at http://mastodon.dev (or at http://localhost:3000 if you haven't installed vagrants-hostupdater). By default, your development environment will have an admin account created for you to use - the email address will be `admin@mastodon.dev` and the password will be `mastodonadmin`.
-
-To stop the server, simply run `vagrant halt`.
-
-## Using the server
-
-You should now have a working Mastodon instance, although it will not federate, as it is not publicly accessible. Should you need temporary federation for development and testing, see the Ngrok information in the [Development Guide](Development-guide.md).
-
-By default, your instance's ActionMailer will use "Letter Opener Web" for email. This means that any email that would normally be sent, will instead be stored, and accessible at http://mastodon.dev/letter_opener - you can use this to verify a registered user account.
-
-## Making changes/developing
-
-You are able to set environment variables, which are used for Mastodon configuration, by editing the `.env.vagrant` file. Any changes you make will take effect after a Vagrant restart.
-
-Vagrant has mounted your mastodon folder inside the virtual machine. This means that any change to the files in the folder(e.g. the Rails controllers or the React components in /app) should immediately take effect on the live server. This allows you to make and test changes, and create new commits, without ever needing to access the virtual machine.
-
-Should you need to access the virtual machine (for example, to manually restart the Rails process without restarting the box), run `vagrant ssh` from the mastodon folder. You will now be logged in as the `vagrant` user on the VirtualBox Ubuntu VM. You will want to `cd /vagrant` to see the app folder.
-
-## Debugging
-
-You can find the Rails server logs in in the `log` folder, which will often have the information you need.
-
-If your Mastodon instance or Vagrant box are really not behaving, you can re-run the provisioning process. Stop the box with `vagrant halt`, and then run `vagrant destroy` - this will delete the virtual machine. You may then run `vagrant up` to create a new box, and re-run provisioning.
-
-## Testing
-
-To run the `rspec` tests and `rubocop` style checker, you may either:
-
-* Install the relevant gems locally, or
-* SSH into the virtual machine, `cd /vagrant`, and then run the commands
-
-## Support/help
-
-If you are confused, or having any issues with the above, the Mastodon IRC channel ( irc.freenode.net #mastodon ) is a good place to find assistance.
+[The documentation has moved to its own repository](https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Vagrant-guide.md)