Connect your website’s RSS or Atom feed once and every new article, release or episode posts itself to Mastodon — on whichever instance your account lives, with a real preview card and nothing to remember after you publish.
Every other network in this series is a single company running a single service. Mastodon is open-source software that anyone can run, which has produced a federated network of thousands of independently operated instances — mastodon.social, fosstodon.org, countless regional and professional servers, and private ones belonging to a single organisation.
Your account lives on exactly one of them. You follow people across all of them, and they follow you back across the network, but the server that holds your account is the one that stores your posts, sets your character limit and enforces its own rules.
For automation this has one enormous consequence: there is no central gatekeeper. No company reviews applications, approves developers or maintains an access tier list. Permission to post is granted locally, by your own account, on your own instance, in a form you generate yourself and can revoke the same way.
That makes Mastodon arguably the most open network PostRSS supports — and the one where the practical questions are about etiquette and instance rules rather than platform approval.
Three things are needed: an account to post to, a token that permits posting, and a feed to read. In PostRSS the account is a Target and each automated post counts as one Task against your plan’s monthly allowance.
In Mastodon, open your account Preferences and find Development. Choose New Application, give it a name you will recognise — “PostRSS” — and select the permission scopes it needs. For posting from a feed, write:statuses is sufficient; there is no reason to grant read access or anything broader.
Saving the application issues a client key, a client secret and an access token immediately. No waiting period, no submitted form, no review queue. The token is what PostRSS needs.
Because the scope is narrow, the token cannot read your notifications, follow accounts, change your profile or delete anything. It can create posts on your behalf and nothing else — and you can revoke it from the same Development screen at any time.
In PostRSS, add Mastodon and provide your instance address together with the access token. The instance matters: @[email protected] and @[email protected] are different accounts on different servers, and the token from one will not work on the other.
Paste the address of your RSS or Atom feed. On WordPress this is usually your domain followed by /feed/, and every category and tag has its own — /category/releases/feed/, for instance. Ghost, Substack, Blogger, Shopify, PrestaShop and OpenCart all expose feeds, as does every podcast host and every YouTube channel.
Publishing on your site is then the only action required. PostRSS checks the feed every 5 minutes on every plan, and every 1 minute on Enterprise.
Mastodon’s default limit is 500 characters, which is generous compared with Bluesky and comfortably fits a headline and a link with room to spare.
But that default is a configuration value, not a law. Instance administrators can and do change it — some servers run 1000, a few run considerably more, and a handful run less. Before assuming a number, check the instance your account is actually on; it is usually stated in the server’s about page.
PostRSS trims the title at a word boundary if a post would exceed the limit, always preserving the link in full. On a 500-character instance this almost never happens with ordinary headlines.
PostRSS sends the item’s title and a link back to the original page. Your instance then fetches that page and builds a preview card from its open-graph tags — the image, the title and the description your site already declares for sharing.
Two details are specific to federation and worth knowing. First, the card is generated by your instance, and other instances may fetch it independently, so a popular post can produce several requests to your server rather than one. This is normal and rarely significant, though it surprises people reading their access logs for the first time.
Second, if the card is wrong, the fix is on your site: correct the og:image or og:description and the card regenerates. As with every other network, the appearance of your posts is controlled by your website rather than by PostRSS.
This is the single most useful piece of Mastodon-specific advice on this page.
Mastodon has historically had no full-text search across the network. Discovery runs on hashtags: people follow tags the way they follow accounts, and a post carrying #RSS or #OpenSource reaches everyone who follows that tag, not only your own followers.
A post with no hashtags is visible to your followers and effectively invisible to everyone else. A post with two or three well-chosen ones can reach a considerably wider audience than your follower count suggests. For an automated feed, this is the difference between broadcasting into a room and broadcasting into the network.
The practical approach is to make sure the tags exist in what your feed emits — many publishers already tag posts in their CMS — and to keep them few and accurate. Mastodon’s culture is notably unforgiving of tag stuffing, and the convention is to capitalise multi-word tags (#OpenSource rather than #opensource) so screen readers pronounce them correctly. That last point is treated as a genuine accessibility norm rather than a style preference.
Because every instance sets its own rules, automation is subject to local policy in a way it is not on centralised networks. Most servers are perfectly happy with feeds. Many ask that accounts posting automatically are marked as bots in the profile settings, and some require it.
Marking an account as automated takes one checkbox in your profile preferences and costs you nothing. It adds a small “bot” label, keeps you compliant with the servers that ask for it, and — perhaps counterintuitively — tends to improve reception, because people know what they are following.
It is worth reading your instance’s rules page once before switching automation on. Servers that dislike unattended posting say so plainly, and it is far better to know in advance than to have an account suspended by a moderator who was never consulted.
If your posting is high-volume, consider a dedicated account for the feed rather than automating your personal one. Many instances make exactly this distinction in their rules.
Mastodon gives every post a visibility setting — public, unlisted, followers-only or direct. For an automated feed, public is almost always right: it puts posts on the public timelines and makes hashtags work as described above.
Unlisted is the interesting alternative for high-volume accounts. Unlisted posts reach your followers and remain fully visible on your profile, but stay off the instance’s public timeline — which is a considerate choice if you publish many items a day and do not want to dominate a small server’s local feed.
Boosts are Mastodon’s equivalent of a repost, and they are the main way a post travels between instances. There is no algorithm to optimise for; a post spreads because people boost it, which again rewards relevance over volume.
Most accounts want a slice of a site. A technical account on a developer instance wants release notes rather than marketing posts. A regional account wants local coverage rather than the national feed.
PostRSS applies filters before anything is posted. You can restrict a Target by category or tag, require a keyword in the title, or exclude one. Several Targets can run from the same feed with different rules, which is how one site feeds an account on a technical instance and another on a general one without publishing twice.
Given how seriously most instances take relevance, filtering matters more here than on networks where an unwanted post simply gets scrolled past.
Instances set their own rate limits, and small community servers are often running on modest hardware paid for by one person. A burst of posts is both impolite and, occasionally, genuinely throttled.
PostRSS’s scheduling controls constrain when a Target may publish, holding items found outside the window and releasing them inside it. For a publisher pushing several items a day onto a volunteer-run instance, this is the difference between being a good guest and being a problem.
People migrate between servers more often on Mastodon than on any other network, and it is worth knowing what that does to automation.
Mastodon’s migration carries your followers across, but your access token does not move — it belonged to an application registered on the old instance. After a migration you register a new application on the new server, generate a new token, and update the Target in PostRSS. Everything else stays as it was.
This is a two-minute job, but it is easy to forget, and the symptom is simply that posting stops. If your automation goes quiet shortly after you moved servers, this is almost certainly why.
Check the access token first. Tokens stop working if the application was deleted, if you revoked it, or if you migrated instances. Also confirm the feed itself updated — a caching plugin serving a stale copy looks identical to a broken automation.
Confirm the scope includes write:statuses. An application registered with read-only scopes will authenticate successfully and then refuse to post, which is a confusing failure the first time you meet it.
That is a filter behaving as configured. Review the category, tag and keyword rules on the Target.
No schedule is set on the Target. Add a publishing window — particularly on a small instance.
Compare timestamps. Under five minutes is the feed-check interval working as designed. Hours means the feed is cached, and PostRSS can only read what your server serves.
Open the article and inspect its open-graph tags. Your instance renders what the page declares, and card generation can lag slightly behind the post itself.
Mastodon deliberately offers no engagement analytics — no view counts, no reach figures, no algorithmic insights. This is a design position rather than an oversight, and it means the usual dashboard is simply not available.
What you have is favourites, boosts and replies on each post, and your own server logs. Add UTM parameters to your links so your analytics can separate Mastodon traffic from everything else; after a month you will know how many sessions the account sends.
Mastodon traffic tends to be lower in volume and noticeably higher in quality than most networks — fewer visits, longer ones, more of them from people who read to the end. Judge it on that basis rather than on raw numbers.
Each Mastodon account you connect is one Target, and each automated post is one Task against your plan’s monthly allowance. Paid plans raise both numbers and add the other networks, and they are chosen on postrss.com rather than inside the mobile app.
Running accounts on two instances — a general one and a specialist one — costs two Targets, and filtering each reduces the Tasks proportionally.
Bluesky is the network most often run alongside Mastodon, and the two setups take about the same time. If you want the same open, self-hosted independence for chat rather than a timeline, a Matrix room is the equivalent — and it bridges to other networks, which Mastodon does not.
Instance rules about automated accounts are a form of the wider question covered in what actually violates platform terms of service, which is worth reading once before automating anywhere.
No. Publishing uses an access token from an application you register in your own account’s Development preferences, scoped to write:statuses. Your password is never involved, and the token can be revoked at any time.
Whichever one your account is already on. If you are starting fresh, choose an instance whose rules and community match your subject, and read its policy on automated accounts first.
500 characters on most instances, but administrators can change that, so check yours. PostRSS trims the title at a word boundary if needed, always preserving the link.
Yes, if it posts mainly automated content. It takes one checkbox, some instances require it, and it improves how the account is received.
No. PostRSS publishes items that appear in the feed after the Target starts running.
Register a new application on the new server, generate a new access token, and update the Target. Your followers move with you; the token does not.
Register the application, grant it write:statuses, connect one feed and publish something. Mark the account as automated, add a couple of accurate hashtags, and watch what gets boosted. Mastodon rewards relevance more directly than any network PostRSS supports — and it tells you quickly which of your posts earned it.
