gyptazy.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
How background workers work in littleFedi
Every littleFedi instance runs a background job queue. Jobs are split by kind, but they all share one thing in common: they sit in a database table and are executed by the "main" worker pool, whose size you control with queue.workers (default min(8, GOMAXPROCS), 1 on the low_power preset).
The kinds fall into two groups:
Heavy, mostly CPU/DB-bound work - inbox (ActivityPub signature verification, actor fetches, home-feed fan-out) and media_cache (image decoding). These block a worker synchronously while they run.
Light, mostly network-bound outbound work - delivery (one signed POST to one remote inbox), its delivery_fanout expander, push_notification, and send_email. These are short and often latency-sensitive: a boost that hasn't landed yet or a push that hasn't arrived is visible to real people.
By default every worker can pick up any kind of job. That is perfectly fine for most instances. The only caveat: job priority only orders queued rows, it cannot preempt a job that is already running. So if a slow inbox or media job is occupying the single (or few) workers, timely outbound delivery, push and email can end up waiting behind it.
light_workers (default 0, disabled) spins up a second, dedicated worker pool for exactly those four light outbound kinds. It is a strict either/or, not extra capacity: with light_workers > 0, delivery, delivery_fanout, push_notification and send_email run only on this pool. The main pool stops touching them, even when idle, and there is no overflow between the two. So workers=8 + light_workers=2 gives outbound federation exactly 2 workers, not 10.
The light pool also yields to interactive requests like the main one does, but with a shorter wait (3s vs 10s) when both compete for the single foreground-recovery slot - so short, people-visible outbound jobs win that one job while every other worker keeps yielding to keep the web UI responsive.
It's totally optional.
With 0 (the default) all four kinds stay on the main pool. The extra goroutine(s) cost is negligible even on constrained hardware.
It can be useful for:
low_power devices (e.g. Raspberry Pi or similar): keep workers=1 for the heavy inbox/media work and enable light_workers=1 so outbound delivery, push and email keep flowing even while your single main worker is blocked on a slow inbox job. This is the recommended combination on a small box.
Instances where inbox/media loads spike: a burst of incoming activity (a big follower purge, backlog of signature-verification work) can stall time-sensitive outbound delivery on a shared pool; giving the light kinds their own pool decouples them.
Visibility matters: push notifications and federation delivery are things users notice immediately; if you care about their latency on a busy instance, the dedicated pool is a cheap way to protect it.
Running a single pool is the right default for most instances. Also note both pools share the DB connection limiter (sized from MaxOpenConns): the database is the serial resource, so worker counts beyond the connection count buy nothing, extra workers just deepens the queue in front of it. Size light_workers for your real outbound throughput.
I just adjusted my relay instance which now also finally supports #GoToSocial! Of course, it also supports Pleroma, snac, Mastodon, littlefedi, starling and many other ones!
With relays, your own posted content gets distributed to all connected instances, as well you get the content all other instances. Currently, mostly tech related instances are connected, focusing on #Linux, #Proxmox, #BSD / #FreeBSD, #IPv6 and many other things!
More information at: https://fedi-relay.gyptazy.com
#socialmedia #fedi #fediwall #fediverse #activitypub #activitypubrelay #relay #social #snac #snac2 #mastodon #gts #gotosocial #littlefedi #pleroma #misskey #services #devops #starling #tech
Hello from the other side!
Yes, it's true. This instance is now running from the Orange PI PC (NetBSD, armv7). It's currently using the SD Card. The performance is...you judge! And it's not set to low_power mode!
smolBSD by @imil could be a nice docker alternative for #littleFedi
I'll perform more tests and will consider to make it an "official deployment method".
Last night, the VPS load monitoring for this instance showed a progressive increase. On one hand, we were expecting it, as the instance grows. On the other, it was higher than anticipated.
Upon investigating, we realised there was an inefficiency linked to two missing DB views, which was generating a mountain of queries whenever a federated activity arrived. Simply creating them was enough: the CPU load upon the arrival of each status dropped from 80% for two seconds to 0.50% for a fraction of a second.
Enjoy the speed 😃
Welcome to #LittleFedi where I am testing out the quote post feature
AodeRelay boostedHello World
This is my first post on Little Fedi #littlefedi
Thank you @stefano for granting me access
Hello World
This is my first post on Little Fedi #littlefedi
Thank you @stefano for granting me access
Just installed netbsd on a home Raspberry pi 3 and connected to a domain via Cloudflare tunnel. Just ready and waiting for the first release of #littlefedi. No pressure @stefano 🤣
Good morning!
I just deployed a new build live. It should resolve the Mastodon API login issue with certain apps. I personally tested it with IceCubes, Ivory, and Mona (though with Mona, it might fail initially, if you hit 'X', it asks if you want to continue with Safari - just select 'yes' to proceed, and it will work. I'll look into it later). It has not been tested with other apps at the moment.
I also merged a couple of optimisations for the PWA and improved the Web Interface, which now uses significantly less CPU. Thanks as always for your help!
The plan is to run a littleFedi instance, once the dust settles.
1) First time running NetBSD on anything, and I only started using *BSD a year ago. Do I need to compile go from source?
2) My ISP needs to provide me with a modem that can run in bridge mode with a static IP. It seems they can only do one, or the other, but not both. Using LTE modem as backup.
3) littleFedi is not yet available (not complaining!)
All the documentation for #LittleFedi is out. Interesting stuff. I have been helping test this project for a couple of weeks and I'm excited. Can't wait for the first beta release
Another step closer to release!
The official website is now live at https://littlefedi.org/ with documentation and project details.
Take a look and let me know what you think!
Logged into littleFedi on an old Nexus 5(x) smartphone that runs Ubuntu touch.
The GUI reacts a bit slow, but that was to be expected.
Otherwise, the timeline and posts render perfectly fine :)
#GoToSocial and #littleFedi keep introducing thoughtful functionality focused on user choice and user empowerment and I'm here for it!
GoToSocial supports importing from previous instance even provides an API for importing non ActivityPub history but both require external tools. littleFedi has built-in backup and full instance restore that seems to be aiming for lower tech know-how. #OwnYourData indeed, hear hear 🍻
@shom @fasnix @madamada Built-in backups of the database, the configuration and, optionally, local owned media, with a manifest and a restore command.
You can fully export all your contents (including posts) and re-import them into another littleFedi instance. It'll be another account with another handle, but you won't lose any of your contents. Your data stays yours.
The self-destruct option in #littleFedi works like a charm. This is perfect for those messages that you don't care about. After all, cleaning out old posts is a great way to reduce storage needs.
I've received quite a few questions about the use of AI in and around #littleFedi.
So, after discussing it within the team, we've decided to update the FAQ and make our position clear.
It probably won't come as much of a surprise to those who already know me and the projects I work on. But littleFedi is reaching people who don't know me, or us, and I think it's fair to explain where we stand rather than assume they already know.
The short version: littleFedi doesn't use AI. No ranking models, no recommendation engines, no language models deciding what you see.
The longer answer, including how I approach LLMs and code contributions, is now in the FAQ:
I've received quite a few questions about the use of AI in and around #littleFedi.
So, after discussing it within the team, we've decided to update the FAQ and make our position clear.
It probably won't come as much of a surprise to those who already know me and the projects I work on. But littleFedi is reaching people who don't know me, or us, and I think it's fair to explain where we stand rather than assume they already know.
The short version: littleFedi doesn't use AI. No ranking models, no recommendation engines, no language models deciding what you see.
The longer answer, including how I approach LLMs and code contributions, is now in the FAQ:
Another step closer to release!
The official website is now live at https://littlefedi.org/ with documentation and project details.
Take a look and let me know what you think!
Another step closer to release!
The official website is now live at https://littlefedi.org/ with documentation and project details.
Take a look and let me know what you think!
Good morning, #littleOne friends!
I pushed a couple of fixes - mostly in the admin interface, and now the composer will auto-collapse on threads, too. The interface should be cleaner now.
Have a great day!
I wonder how accessible littleFedi is?
Starting with all the color combinations offered in the different themes (appearance of the timeline and the blog).
I know that you can write your own CSS, but the themes should be accessible in standard settings, without the need to change anything.
Its been some time since I've setup a home server, and even then I only used it to store backups from devices on the LAN.
Never hosted anything that is reachable from the internet (besides SSH). I want to learn how to self-host a few services, starting with a Google Photos replacement; and littleFedi by @stefano .
Thought of using a old laptop, but decided to step up to a ThinkCentre M720q. I've installed FreeBSD as the host OS.
Onward!
@stefano Hi! I'm about to spin up a small fedi instance, and was considering my options when #littleFedi was recommended to me, and I liked what I've read.
Is the source available in one form or another, so that I can try self-hosting it?
I don't care if it's pre-alpha software, I run plenty like that, and the instance I plan to spin up is expendable, and won't have anything important on it. So a perfect place to play with heavily in development software!
I tracked down a bug that caused some notifications to fail during a blog regeneration if all the workers were busy. If I haven't replied to you, it's because I might not have seen your messages.
The latest build should have fixed the issue. Sorry about that!
@mboelen
Look at that, #littlefedi does that correctly and announces itself also clearly. 👍
2026-08-10T13:04:01+00:00 200 XYZ "GET /self-hosting/running-your-own-mailserver/ HTTP/1.1" 35603 "-" "littleFedi/26.08.09 (link preview)" TLSv1.3/TLS_AES_128_GCM_SHA256 0.000 .
2026-08-10T13:04:01+00:00 200 XYZ "GET /opengraph/background_hu_e4b2de6594c40996.png HTTP/2.0" 78766 "-" "littleFedi/26.08.09 (media proxy)" TLSv1.3/TLS_AES_128_GCM_SHA256 0.001 .
It looks like littleFedi is supporting gzip, but not Brotli yet (gzip=35603 bytes, brotli=24350 bytes). Both Brotli and Go developed by Google, I will list this on the "nice to have" in my feedback to @stefano 😄
Nice example of the opposite: Pleroma does not support compression at all (so it would like the version with 132715 bytes, uncompressed). So that software simply wastes a lot of bandwidth, especially if you consider how much links are shared. So yes, I block those requests and return a 406
2026-08-10T13:04:08+00:00 406 1.2.3.4 "HEAD /self-hosting/running-your-own-mailserver/ HTTP/1.1" 0 "-" "Pleroma 2.10.2; https://xyz <xyz@xyz>; Bot" TLSv1.3/TLS_AES_256_GCM_SHA384 0.000 .
Het leuke aan de #Fediverse (waar Mastodon ook onderdeel van is) is dat er steeds nieuwe oplossingen bij komen, die aanhaken in het grotere geheel. Vaak zijn het proefballonnen en komt het merendeel niet echt van de grond.
Ben nu #littleFedi van @stefano aan het testen en kan oprecht zeggen: wow 🤯
Het zou een lichtgewicht implementatie moeten zijn en de software is nog in de testfase, maar voelt nu al beter in elkaar gezet dan Mastodon. Supervriendelijke interface, focus op de dingen die er daadwerkelijk toe doen zodat je minder ruis hebt. Gelijktijdig heeft het een geweldige optie voor kennisdeling, zoals een ingebouwde blog. Zo kun je "vlugge" posts maken (inclusief self-destruct per bericht!), maar ook zaken die je voor de langere termijn wil bewaren, opslaan als blogpost.
Veel software: 😡 🤮
littleFedi: 😍
Dit is hoe software hoort te zijn: focus, simpel, handige opties.
Helaas is het nog "invite-only", maar voor iedereen die overweegt om een eigen installatie op te willen zetten, hou littleFedi in de gaten.
Bij deze meteen een test om te zien als ik naar mijn eigen profiel link:
I love the new "What is worth sharing" expandable section. Much cleaner and less confusing, especially for #littlefedi newbies
It's still very early, but littleFedi looks very very promising. Sure, I already see some minor improvements (that's why I am helping with testing), but this might be the better "mouse trap". Or let me say it in other words: maybe this is what Mastodon should have been? 🤯
I know more people want to share their knowledge, but can't be bothered to start a full blog. The option for people to create their blog here, that's really powerful.
Well done @stefano 🚀
Just a little reminder on littleFedi's efficiency
The instance https://rpi0w.stefanomarinelli.it - with my user @stefano@rpi0w.stefanomarinelli.it - has been running for over a month on a Raspberry Pi Zero W powered by NetBSD.
Under normal operation, it uses 58 MB of RAM, including caches. And it shows no signs of slowness!
So this is my very first interaction with littleFedi. I'm amazed by how well it looks !
So let's keep this post simple and share its website: https://littlefedi.org/
LittleFedi asks in the compose field:
"What is worth sharing?"
Interesting question 🤔
Other clients ask, e.g.:
"What's on your mind?"
(you don't want to know, really 😁)
or
"What are you doing?"
(nothing really, watching my timeline fly by)
Another question could be:
"Have you really thought about what you are about to share with the public / whole wide world?" 🤔
I like the catch-up feauture on LittleFedi ! So easy to just take a glimpse of the timeline without scrolling full day 👍
#littlefedi
Hej, I'm Florian, or Flo for short (only my family calls me with my full name).
Born 1977 as a gay person, and raised near Lake Constance in the south of Germany.
After my parents got a divorce and my father met another woman, we moved to Dresden, when I was 15.
Lived here until I started my apprenticeship in 2000 in Lindau (Lake Constance), so moved back again.
After being self-employed (ebay seller and creating simple websites), which unfortunately wasn't sustainable, I took a job in the security branch, however only got contracts for one year (three times), until I moved back to Dresden in 2010 and lived here ever since.
Since 2018 I have a dog, which you can see in my header picture, when we took a walk along the river Elbe.
Currently unemployed (since May '24), IT-support (thanks "AI", which overtook my profession, I guess).
Interested in too many things, like minimalism, barefoot shoes, cycling, music, interior design, and much more.
I was a twitter "power user", from 2009-2022.
Created my first account in the fediverse on mastodon.social in 2018, however only used it sporadically.
Since the end of 2022, I exclusively use the fediverse and experienced different network software (mastodon, akkoma, pixelfed, and now littlefedi).
That's it as an introduction for now 😀
PS: English is my first foreign language, so please bear with me in case of errors.
The "Catch-up" timeline is 👌
I often feel like I can't keep up with my home feed. Now I don't have to worry about that so much 🙂
Added the /blogs route, with a list of all the published blogs. It's opt-out, so you can disable it in your settings page: https://littleone.littlefedi.social/blogs
RE: https://littleone.littlefedi.social/@stefano/4252ae6f-b949-42f8-a021-fd2b698f8b37
Felice di sapere che sta prendendo vita #LittleFedi, un nuovo server ActivityPub che non necessita di grandi risorse tecniche e conoscenze pratiche per essere installato ed usato. Questi sono i progetti che fanno la differenza! 👍
littleFedi: a Fediverse Server That Doesn't Need a Data Centre
I was fifteen, and there were no BBSes in my city. So every call was long distance, once a day, sometimes twice. I'd start the dialer and wait for that sound - the handshake, the negotiation, the hiss settling into a carrier - and then I was connected to a computer sitting in somebody's bedroom, a few hundred kilometres away. I was a co-sysop of a local board and a national moderator of a FidoNet area. None of my friends understood what I was doing, and they'd stopped asking to avoid an incomprehensible monologue. But I liked it, and that was enough for me.
Here's the thing about that computer in someone's bedroom. There was no data centre. No domain, no certificate authority, no hosting provider, no cloud. Just a machine, a phone line, and a person who'd decided to run it. If you wanted to reach it, you called it.
Now look at what it takes today to put a small server on the network so other people can talk to it. A public address, which most home connections no longer have. A domain, which you rent. A certificate, which somebody has to issue you. And, increasingly, a VPS somewhere, because the software won't fit on the hardware you already own.
We've added a lot of infrastructure between two people who just want to talk. That's what littleFedi is about.
What it is
A single Go binary. No Ruby, no Sidekiq, no Redis, no separate worker processes to babysit. You run
init, answer a few questions, and you've got a working instance. It speaks ActivityPub, and it speaks the Mastodon client API well enough that existing apps just work.It also runs on hardware that would make Mastodon - or even Akkoma - struggle. Most software in this space assumes a VPS with a few gigabytes of RAM and a database server next to it. We assumed a Raspberry Pi Zero W behind a home router. There's a
low_powermode that tunes memory use, image decoding and thumbnail generation for exactly that kind of box, and it's tested on that kind of box, not just on a fast dev machine.In spirit this puts littleFedi close to snac, which I've always liked a lot. Same conviction: a personal server shouldn't need a fleet of services behind it.
Federating without a public address
littleMesh is the part I'm most attached to, and it's the part that goes back to the modem.
Your instance generates an Ed25519 key pair. That key is its identity - the node's address is derived from the public key, so reaching that address means reaching the holder of that key and nobody else. No registrar, no certificate authority, nobody to ask permission from.
A small set of public lighthouse nodes help two instances find each other. Once they're introduced, the traffic runs over a second TLS session pinned to both node IDs. The lighthouse copies encrypted bytes back and forth. It never sees plaintext, and it can't impersonate either side. And if the two nodes can reach each other directly, they drop the relay after the introduction and talk peer to peer.
Which is, more or less, calling the BBS directly. Just without the phone bill.
The gateway into ordinary HTTPS
Mastodon and other regular servers can't resolve a mesh address on their own. There's no domain and no certificate for them to find.
That's what the optional HTTPS gateway is for. A lighthouse operator can run one alongside the relay, and it bridges the mesh into ordinary HTTPS for the rest of the web. The gateway has to terminate TLS to do that, so it can technically see the traffic passing through it. Which is exactly why it's a separate, opt-in piece and not something every node exposes by default.
It has two independent settings: one controls what the gateway lets ordinary internet visitors reach at all, and a second one applies again at the destination node. Left at their defaults, both allow only federation traffic - ActivityPub delivery, discovery, public media. Web login, API and media proxy stay closed unless an operator deliberately opens them.
Mesh peers talking to each other directly never touch the gateway at all. That exposure only applies to the bridge into the wider web. And all of this can be self-hosted.
Chronological timelines
Timelines are chronological. Nothing gets reordered by an engagement model.
If you want something closer to "what did I miss", there's a separate
/catchuppage you visit on purpose. It ranks posts using signals your own instance already has - how many people you follow boosted something, whether it continues a conversation you took part in. No external popularity score, no telemetry, nothing leaves the machine. You press "mark as read", it moves a divider, and that's the only thing it remembers.Self-expiring posts
You can set a post to expire, with its own timer, instead of a fixed instance-wide setting.
This isn't a client-side trick that hides the post from view. The expiry goes on the same durable job queue that runs the rest of littleFedi's background work, so the deletion survives restarts and isn't lost if the process happens to be down at the moment the timer fires. When it does fire, the post is deleted and a real Delete activity goes out to everyone who received it - so it actually disappears from remote instances too, not just locally. Editing the post before then can push the timer back or cancel it.
Static blogs, with real threaded replies
littleFedi can take a Fediverse post and publish it as a page on a plain static blog, with its own Atom feed and permalinks that don't move even if you edit the post later. No JavaScript, no database hit on page load.
The part I find more interesting is that the replies aren't left out. If the author turns the option on, littleFedi pulls the public replies that were actually federated to the post, threads them the same way the timeline does, and bakes the whole tree into the generated HTML at build time. So a blog post can show a real comment thread, in the same static file, with the same guarantee as the rest of the page - no JavaScript, no live queries. Only public and unlisted replies qualify, obviously. Anything followers-only or direct never enters the picture.
Why it looks like this
This isn't minimalism for its own sake. It's about how many people simply can't run their own server today, because the requirements are too steep. The hardware, the ops complexity, or just needing a domain and a public address before you can start. We're trying to remove those barriers one at a time, while still shipping a real, federating, reasonably complete server: polls, quotes, scheduled posts, MFA, PostgreSQL and S3 if you want to scale up later.
I've written before about taking a semi-truck to buy salad. Hardware keeps getting more expensive and the software running on it keeps asking for more of it every year. That's backwards. If the machines cost more, the operational cost of what sits on them should go down, not up. Same with complexity: the default direction is to keep adding it, and we'd rather strip it out.
And there's the other half, which is closer to why any of us are doing this at all. It's the same thing that drew me to snac and to the way grunfink works on it, and the same thing that had me dialing a stranger's computer at fifteen. People building tools so that people can talk to each other. Nothing more dressed up than that. We'd rather show the servers running, talk about the Pi sitting in the corner, share a tiramisu photo if it comes up. The joy in this was never about the money it brings in. It's about what we end up building, humanly, because of it.
It's beta software, still short of a first release, and I'd rather say that plainly than oversell it. But it runs, and it federates. That's the part I wanted to write about.
Hola mundo!
Rozando el medio siglo de existencia creía que lo había visto prácticamente todo, no era así.
De vez en cuando, entre toda la miseria que se mueve en este nuestro planeta, surgen iniciativas que te transportan a otras épocas. Unas en las que todo era mucho más sencillo, menos complejo y donde la tecnología era algo comunitario, casi mágico en algunos aspectos.
@stefano ha conseguido con #littlefedi poner de nuevo el foco en lo esencial, en lo simple, en lo eficiente. Volver a tener el software a tu servicio y no al revés.
Larga vida a littlefedi!
Not heavily tested and probably still full of bugs, but I just shipped the visual editor build.
Looking forward to your feedback!
Everyone loves text formatting, but not everyone loves Markdown.
We've got you covered.
I'm merging a branch that includes a WYSIWYG editor, which will translate the output directly into Markdown.
No more tags to remember when writing your next post (or blog post), just a convenient, predictable editor.
What do you think?
The next branch I'm going to merge into main contains something a lot of people will like. I won't spoil anything, but it addresses one of the most frequent criticisms I've seen regarding similar solutions... stay tuned!
littleFedi media management
Are you worried that your low-power device will be overwhelmed by external media caching?
Don't worry, we've already thought of that!
littleFedi offers 4 media management options:
For both caching modes, you can store media locally or use an external S3-compatible service. Moving between storage types is supported natively, without needing external tools like rclone.
New littleFedi build on littleOne
littleFedi 26.08.09 - the changes in this build compared with the previous
deployment.
Your followed hashtags are now one click away: a Hashtags entry (with a
hashtag icon) has been added to the desktop navigation bar and the mobile
account menu, pointing at /tags. The label is translated in every supported
language.
Posts that have been published to the blog now carry a small Blog chip in
the status meta line. It links to the post's readable permalink
(/@user/blog/<slug>/) and works on timestamps and boosts, so readers can jump
straight from the timeline to the polished blog version of a long post.
Every marker on a status - visibility, language, blog chip, expiry - is now
rendered as the same uniform chip in a single wrapping flex row, instead of a
mix of right-aligned inline boxes. Posts that carry several markers read as one
neat line rather than a ragged stack. The Ink and Roost themes were adjusted to
match.
Previously a post whose author account no longer resolves (a purged account, or
a partially hydrated cache entry) could fail the whole timeline render. Now any
status - including the target of a boost - whose author is missing is silently
skipped. Covered by a new test.
If you publish a blog, regenerate it so the fixes apply: Settings → Blog
appearance → Rebuild blog now. The blog's style.css is assembled at build
time, so it only picks up these changes when you rebuild.