Fedi Monster 👻

We automatically prune attachments (remote files stored by your instance, 'cached') about every 2 weeks.
Files older than 90 days will be considered for deletion, and it will show up as Tasks and free up media storage space.

Once every few months, extra jobs are done in this periodic task. They will clean up any forgotten attachment, and then try to compact the database by removing remote statuses that have not been interacted with.

You might have access to settings overrides in Mastodon's own settings, but the 90 days limit is enforced by our file storage provider and so going lower will not actually free space.

Yes, but: as currently implemented in Mastodon, relays are extremely inefficient and costly, and so we need you to use it sparingly and avoid large relays.

Subscribing to a relay will basically make a local copy of all posts and media from the relays over to your instance, which will use a lot of processing power, as well with large amounts of media and database storage, most of which will never be read back. It can easily make even a single user instance use as much resources as a thousand-users instance.

You will need to switch mail servers. Maintaining a mail server is not an easy task, and to guarantee service quality we chose not to assume that role for now.
You can use any external mail server on your instance, or a default one provided by Fedi.Monster (sending mail from a generic domain).

Compatible providers include:

• Dedicated services with free plans like Sparkpost or Mailgun;
• Mail services with SMTP access (and supporting the use of a custom domain) like FastMail, Zoho, ...

Yes, all we need is your original instance configuration (probably as a .env.production file)
and the complete database copy (using pg_dump).
If you are using another managed service, look for a backup or export feature.

If your instance uses an external storage service, we can then transfer files to ours while the instance is running. If it uses local storage instead, it must be uploaded to our storage service, by sending us an archive or using S3-compatible tools to upload them directly.

You can also let us handle all that and make sure it's restored perfectly. Please send an email or open a ticket for more information.

Yes, portability is one of our priorities. You can request an archive of your instance and restore it to your own Mastodon server or another hosting provider.

In the archive, you will find:

• a full PostgreSQL database that you can restore using pg_restore;
• a mastodon_env.txt file containing environment variables as when running on Fedi.Monster.

Uploaded media is not included as it is usually the heaviest part, but you can also migrate it from information included in the mastodon_env.txt file. It can be done using s3cmd or minio client:

./mc config host add maass3 https://objects.fr1.maas.network AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY --lookup path
./mc mirror maass3/S3_BUCKET/ /home/mastodon/live/public/system/

This method can be used to get the files locally, or directly transfer them to another S3-compatible object storage. Replace AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and S3_BUCKET by their value in your mastodon_env.txt.

• Our servers are mainly located in Germany, at Hetzner. This is where data is stored and processed.
• We store attachments in Wasabi, a third party cloud service, in its 'central EU' regions located in Amsterdam and Frankfurt.
• We operate our own CDN over servers spread across Europe for increased availability, currently in France and Germany. This is where your browser and apps will connect to.

Unfortunately, no. Opening direct access would require much more isolation between instances, and in turn drive up the costs.

Some actions are available from your control panel. If you need anything else done, please open a supprt ticket.

If you want to have full access over your instance, we can set up a dedicated instance for you, for a slightly higher cost.

Decentralization is as much about who is administrating than it is about where and how it is hosted.

We centralize hosting, but not administration. Some centralization has very valuable perks, like making it much easier for anyone (not only experienced sysadmins) to own a Mastodon instance and participate in the federation, or pooling up resources to share a powerful infrastructure even with small instances. But it becomes a single point of failure: more instances will risk having issues at the same time, and a few people get more responsibility and power over the network.

We believe our service can be very useful and can help many instances exist in good conditions, or exist at all. But Fedi.Monster doesn't aspire to host all Mastodon instances, we only want to make having a Mastodon instance easier and available to more people, especially those who can't self-host for any reason.

At signup, only an username and password (for authentication) and an email address (for important notices about your account and customer support) will be required and stored. (the password is securely hashed, and only the result is stored)

All payment information are stored by our payment processors, and on our side only with an identifier to the customer through the relevant payment processor. You may link your credit card, in which case we will only store an identifier for the card, the actual credit card information being held safely by Stripe.

All this information is used exclusively by Fedi.Monster and will not be shared with a third party without authorization from the account owner. As detailed by the terms of service, instance data will also be kept confidential, unless requested by the account owner. Instances are regularly copied for backup purposes. This does not include any operation that the instance software will do on its own.

To monitor user activity, we will store the last successful login date and the account creation date. Support tickets will be stored so they can be read by our staff, and used as internal knowledge base.

Statistics from the hosted instances will be regularly collected for billing purposes and published for general interest: local and total count of users and statuses, peered instances, stored media size and database size.

This website and instances are hosted in Europe. In the default configuration, instances use Mailgun to send e-mail.

Most information mentioned here is visible and modifiable in your account settings, anything else may be requested by contacting our support.
Instances can be fully exported through an automated process, and restored using freely available tools.

Account can be disabled on demand which will only leave the username, payment history, support tickets, and instances.
30 days after instance cancellation, instances will be deleted from our production servers. Backup archives may be kept for up to a year after deletion.

Not much!!

The user and size limits are mostly indicators, and your instance won't be destroyed and you won't be overcharged if you go over them.
Usually that will simply lead us to talk about switching to another plan whenever you're comfortable with it.

If payment fails, nothing will be cut off either, we will eventually be in touch about updating your payment info, and if we don't hear back for 6 months we will consider shutting down the instance.

We currently support contributing to our OpenCollective account which should let you pay by credit card, PayPal, SEPA debit, Bancontact, and direct bank transfers.

If you have your own collective registered there, you may contact us to receive a recurring expense directly to your collective. Please contact us if you need anything else.

We do not offer any business class of managed hosting plans: you're welcome to subscribe to our services and donate generously accordingly to your means as a company, but be aware that this hosting service is still community-run, and has certain non-negotiable constraints :

1. If you have much larger needs than any community we host, we will have to reject your offer. Our service is primarily meant for small to medium instances. At thousands of active users, it becomes inoptimal to share hosting, and you should have a dedicated solution, with dedicated hardware and staff.
2. There will be no service level agreement over Best Effort: under no condition will we contractually guarantee you any uptime; even if it seems flawless in practice. We are simply not able to back this strongly with our current means, and doing so would cost more than anyone wants to spend on a mastodon instance. We will do what we can and follow best practices, but we can't afford to have people on call 24/7.
3. We can't give you any legal guarantees either. There is no hosting company you can sue if things 'go wrong'. We're pretty confident we won't suffer any major security breach, or have to stop service in an emergency without a comfortable warning delay; but if it happens that's the end of it, you trusted talented amateurs with no capital or larger support structure, and they can only do so much in this chaotic world.

We do not provide any dedicated hosting solution as of now.
Our members might be available for consulting work to accompany you in building such solution over an existing hosting platform that can follow your needs. In doubt, you're welcome to send an email.