Mastodon Instance Hosting Cost Calculator

Plan a realistic monthly budget before your instance gets busy

Running a Mastodon instance is closer to operating a small public service than launching a static website. A quiet community can sit happily on inexpensive hosting for a while, but the bill changes once people start uploading media, following remote accounts, and generating federation traffic all day. This calculator helps you estimate that monthly bill in a way that matches how instance costs usually emerge in practice. Instead of guessing whether your current setup will still feel comfortable next month, you can translate user activity into a number built from the three hosting components that most often matter first: the base server, stored media, and network transfer.

This matters because Mastodon hosting has both fixed and variable pieces. You normally pay some baseline amount for compute and memory even on a slow month, but every active account also contributes storage growth and outbound bandwidth. The calculator separates those moving parts so you can see whether the pressure is mainly coming from a larger server, heavier media retention, or more federation traffic. That is much more useful than a single vague estimate, especially if you are deciding on donation goals, sponsorship needs, or whether your current hosting plan has enough headroom.

The tool is designed for rough monthly planning, not exact invoice prediction. That is the right level of precision for most administrators. If you are comparing a community server, a niche interest instance, or a private organization instance, the useful question is rarely the exact cent value. The real question is whether your current assumptions are in the right range and which cost driver deserves attention first if growth continues.

How to choose each input from real instance data

Active Users should represent the people who are actually active in a typical month, not the total number of accounts ever registered. Dormant accounts may take some space, but they do not behave like everyday users who browse timelines, upload attachments, and trigger federation delivery. If your dashboard reports monthly active users, that is usually the cleanest source. If you only know total accounts, it is safer to estimate conservatively and then test a busier scenario rather than assume everyone is equally active.

Average Storage per User (MB) is the average local media footprint tied to each active user. Think of it as the amount of disk usage that accompanies a representative member of your community. On a text-heavy instance it may stay modest. On an art, photography, or event-focused instance it can rise quickly. The right number may include attachments, avatars, custom emoji, and sometimes cached remote media if your storage policy keeps those files around. If you already have an instance, a practical way to estimate this field is to divide occupied attachment storage by active users and then round up a little to allow for growth.

Monthly Bandwidth per User (GB) is often the most misunderstood field, because it includes more than just what local users upload. Every timeline refresh, media view, avatar request, and federated delivery to or from remote servers consumes transfer. That means bandwidth can spike during viral posts, busy event coverage, or waves of remote followers even if the local user count did not change much. If you can, base this number on a representative month from your hosting provider or CDN analytics rather than a single unusually quiet week.

Base Server Cost ($/month) is the fixed monthly charge for the core machine or service bundle that keeps the instance alive. In some setups that is a single VPS bill. In others it may represent a larger combined baseline that includes database, Redis, search, object storage gateway, or managed service fees you pay regardless of traffic. The important point is that this field captures the cost floor that exists before per-user storage and bandwidth are added.

Storage Cost ($/GB/month) and Bandwidth Cost ($/GB) are the provider rates for the variable parts of the bill. If your host publishes a price card, use those numbers directly. If your invoices are bundled, you can still estimate an effective rate by dividing the usage charge by the number of gigabytes consumed. Try to keep the units aligned with the form. The storage field expects megabytes per user, but the storage price expects dollars per gigabyte per month, so the calculator converts megabytes to gigabytes internally.

If you are unsure about any of these values, the most reliable workflow is to run three scenarios: a normal month, a cautious high month, and a growth month. That way the calculator becomes a planning range rather than a single fragile point estimate. For infrastructure decisions, that is usually the better habit.

What usually changes a Mastodon bill the fastest

On many small and mid-sized instances, bandwidth is the first variable to surprise people. Media-heavy timelines, link previews, remote followers, and general federation chatter all generate network traffic. The community may feel stable while your egress line item rises month after month. If you run an instance centered on art, memes, event photos, or video clips, bandwidth often deserves the most testing.

Storage usually grows more quietly. It may not dominate the first bill, but it tends to accumulate. If you keep uploads indefinitely, retain large files, or maintain generous caches, storage behaves like a long-tail cost that follows you even after a busy signup period ends. Backups can double that pressure if they live in paid storage too, so many administrators treat the calculator’s storage result as the start of the conversation rather than the full total.

Server cost is often a step change instead of a smooth slope. You may be comfortable on one server plan for months and then suddenly need more CPU or RAM because the database, queues, or background jobs no longer feel responsive. That is why this calculator keeps server cost separate from the per-user charges. When the result moves, you can tell whether you are still in a usage-scaling problem or whether you are nearing the next infrastructure tier.

How the calculator turns your inputs into a monthly estimate

The script uses a simple cost model that is easy to audit. First, it multiplies active users by average storage per user and converts the result from megabytes to gigabytes by dividing by 1024. That gives total stored data. Next, it multiplies total stored data by the storage price to get monthly storage expense. It also multiplies active users by monthly bandwidth per user and then by the bandwidth rate to estimate transfer expense. Finally, it adds those two variable charges to the fixed server cost. The result panel shows both the total monthly estimate and the average cost per active user.

In that formula, C is total monthly cost, S is base server cost, U is active users, M is storage per user in megabytes, B is bandwidth per user in gigabytes, c_s is the storage rate, and c_b is the bandwidth rate. The per-user figure shown in the result is simply C divided by U. That second number is often helpful when you are deciding what level of recurring donations or organization support would make the instance sustainable.

If you like to think about calculators more generally, the same process can be viewed as a result generated from several inputs and then summed into a single monthly estimate. The following MathML blocks express that broader idea and are preserved here for readers who want the abstract structure behind the script.

For this hosting calculator, those weights are the conversion and pricing terms. Dividing by 1024 converts megabytes to gigabytes. Multiplying by storage and bandwidth rates translates usage into dollars. Once you see that structure, it becomes easier to test scenarios intelligently: if one input doubles, ask whether the output moves in the direction and proportion you would expect.

Worked example using the default values

Suppose you enter the example values already shown in the form: 100 active users, 500 MB of storage per user, 2 GB of bandwidth per user, a base server cost of $25 per month, storage priced at $0.02 per GB per month, and bandwidth priced at $0.05 per GB. The calculator computes total storage as 100 × 500 MB = 50,000 MB, which converts to about 48.83 GB after dividing by 1024.

• Storage expense = 48.83 GB × $0.02 ≈ $0.98 per month.
• Bandwidth expense = 100 × 2 GB × $0.05 = $10.00 per month.
• Total monthly hosting cost = $25.00 + $0.98 + $10.00 = $35.98 per month.
• Per-user monthly cost = $35.98 ÷ 100 ≈ $0.36 per active user.

That example highlights an important planning lesson. In this specific scenario, storage is almost irrelevant compared with the fixed server and bandwidth costs. If you were trying to reduce the bill, attachment retention would matter less than bandwidth policy or server right-sizing. On a photo-heavy or video-heavy instance, the outcome can reverse, which is exactly why scenario testing is useful.

A second quick test shows how sensitive the estimate is to traffic. If everything stays the same except bandwidth rises from 2 GB per user to 4 GB per user, the bandwidth expense doubles from $10.00 to $20.00 and the total monthly estimate rises to $45.98. That is a clear signal that the instance, as modeled here, is more exposed to network activity than to disk growth. This sort of one-variable adjustment is one of the best ways to turn a calculator into a decision-making tool.

How to use the result for planning instead of just curiosity

Once you have a result, interpret it as a monthly planning baseline. If the estimate looks manageable in a normal month, test a busier month next. Increase only one uncertain field at a time so you can tell what is driving the change. Administrators often learn more from three simple runs than from one overcomplicated spreadsheet because each run answers a specific question: what happens if active users rise, what happens if media retention is heavier than expected, and what happens if federation traffic becomes unusually busy.

Always sanity-check the units before trusting the output. A suspiciously low result usually comes from a unit mismatch, not magical efficiency. If your analytics report daily bandwidth but the form expects monthly bandwidth, multiply first. If your storage figure is already in gigabytes, do not enter it in the megabytes field without converting. The calculator’s math is straightforward enough that a surprising number is usually pointing to an input interpretation problem, not a hidden bug.

It also helps to separate budgeting from procurement. Budgeting asks whether the cost range is acceptable. Procurement asks which provider or configuration best meets that range. This calculator is strongest on the first question. If the result says your community is likely to sit around a certain monthly total, you can then decide whether a larger fixed server with cheaper bandwidth, or a smaller server with a CDN or object storage, gives you the best real-world balance.

When you plan for a live community, rounding up is wise. Add buffer for backups, object storage overhead, snapshots, outbound email, monitoring, abuse spikes, and moments when a single popular post sends more media traffic than your average month would suggest. A good rule is to treat the computed number as the floor of a reasonable budget and then reserve extra margin according to how predictable your community is.

Assumptions and limitations to keep in mind

This page models only the variables shown in the form. It does not directly price moderator time, support work, legal review, domain registration, payment processing, transactional email, CDN contracts, managed database premiums, search services, or long-term backup retention unless you intentionally roll those into the base server field. If your production setup includes multiple hosted services, use the base server input as your combined fixed baseline or remember that the result represents only one slice of the total operating cost.

The model is also approximately linear. Double the users and the storage and bandwidth components double too. Real Mastodon instances do not always behave that neatly. Caching may flatten some traffic. Media-heavy communities may grow faster than linearly in cost. A sudden surge of new users can force a larger server tier before the variable charges seem dramatic. Conversely, a well-tuned instance with aggressive media policies may scale more efficiently than a naïve average suggests. That is why it is sensible to compare at least a normal month and a stressful month before making commitments.

One final practical question helps make the estimate more meaningful: what happens if your busiest recent week became a typical month? If that scenario still looks affordable, you are probably working with a healthy buffer. If it looks uncomfortable, the calculator has already done valuable work by showing which lever matters most. Maybe you need a bigger server floor, maybe you need clearer media policies, or maybe you simply need donation targets that reflect the real cost of running a federated community.