nachitima

I’m considering starting a Lemmy instance with a limited federation model, and one of the things I’m thinking about from the start is how to support and maintain it as it grows, while spending as little attention as possible on the technical side of infrastructure management itself.

Because of that, I’m especially interested in hearing from admins who host Lemmy instances, particularly larger ones. I’d like to understand what your actual workflow looks like in practice: how you organize administration, what methodologies you use, how you handle backups, data recovery, upgrades, monitoring, and infrastructure maintenance in general. I’m also interested in whether there are any best practices or operational patterns that have proven reliable over time.

From what I’ve found so far, the official Lemmy documentation on backup and restore seems reasonably good for small instances, but as the instance grows, more nuances and complications appear. So ideally, I’d like to find or assemble something closer to a real guideline or runbook based on practices that are actually used by admins running larger instances.

If you run or have run a Lemmy instance, especially one that had to scale beyond a small personal or experimental setup, I’d really appreciate hearing about your experience. Even brief notes, links to documentation, internal checklists, or descriptions of what has and hasn’t worked for you would be very useful.

cross-posted from: https://lemmy.ml/post/44219906

I’m still working on the PeerTube-Browser project and wanted to share a small update on what has been happening lately.

Since the previous post I made several changes that are probably not very visible from the user side, but they are quite important from an architectural perspective.

Engine and Client separation

I split the system into two separate components: Engine and Client.

The Engine is essentially a service that crawls data from PeerTube instances. It collects and indexes that data and exposes it through an open REST API.

The Client then communicates with the Engine through this API to fetch the data and display it to the user.

The idea behind this separation is to make the Engine something that can run more or less autonomously. In the long term it should be a service that you can just start and let it run without much moderation or manual intervention. At most it might require occasional moderation of things like instances or channels.

So the Engine’s responsibility is simple: collect data, index it, and provide access to it.

The Client’s responsibility is different: take that data and present it to users in a useful way.

Because the Engine exposes a public API, it also opens the possibility for other integrations. In theory anyone could build their own front-end, client, or integration using the data the Engine provides. For example, someone could create a page on a PeerTube instance that shows videos only from that instance’s federation, or build alternative interfaces or tools on top of the same dataset.

At the moment the API is still undocumented and evolving. The Client already communicates with the Engine through it, and technically anyone can query the Engine at:

engine.peertube-browser.com

There are a few endpoints available that return data, although they are still experimental and will likely change as the system develops. The plan is to gradually expand and stabilize this API so it becomes more flexible and useful for building additional tools, integrations, or alternative frontends.

Current work

Right now most of my work is focused on the development workflow, particularly how to work with AI agents inside the project.

As the project has grown, I started running into some limitations and practical problems when using agents for development. Because of that, I’m currently designing a workflow that helps structure this process better.

Part of this work also involves figuring out how to track and present development progress publicly on GitHub. I want to create a workflow that allows me to keep transparent records of development activity while also automating some repetitive parts of the process.

The goal is to optimize how I interact with AI agents during development and make it easier to show progress publicly as new features are implemented.

What’s next

I already have a rough plan for the functionality that should eventually be implemented. For now I’ll keep moving forward step by step following that plan.

Feedback from the previous post was very helpful, and I’m taking those comments and suggestions into account. If you have ideas, thoughts, or criticism — feel free to share them.

Support

At the moment the project is funded entirely by me. I’m building it not for personal use, but because I think it can be useful for others and because I genuinely enjoy working on it.

Also, to be honest, working on something meaningful helps keep my mind occupied during the war here in Ukraine.

If you find the project interesting or useful, and you want to support its development, I would really appreciate it. Seeing that people care about the project and use it is a huge motivation to continue working on it.

You can support the project in two ways:

• Patreon — for recurring support
• Donatello — a Ukrainian service that allows one-time donations directly to my Ukrainian bank account

Project's repo:

https://github.com/denikryt/PeerTube-browser

Any support, feedback, or ideas are very welcome.

Thanks for reading.

I’m still working on the PeerTube-Browser project and wanted to share a small update on what has been happening lately.

Since the previous post I made several changes that are probably not very visible from the user side, but they are quite important from an architectural perspective.

Engine and Client separation

I split the system into two separate components: Engine and Client.

The Engine is essentially a service that crawls data from PeerTube instances. It collects and indexes that data and exposes it through an open REST API.

The Client then communicates with the Engine through this API to fetch the data and display it to the user.

The idea behind this separation is to make the Engine something that can run more or less autonomously. In the long term it should be a service that you can just start and let it run without much moderation or manual intervention. At most it might require occasional moderation of things like instances or channels.

So the Engine’s responsibility is simple: collect data, index it, and provide access to it.

The Client’s responsibility is different: take that data and present it to users in a useful way.

Because the Engine exposes a public API, it also opens the possibility for other integrations. In theory anyone could build their own front-end, client, or integration using the data the Engine provides. For example, someone could create a page on a PeerTube instance that shows videos only from that instance’s federation, or build alternative interfaces or tools on top of the same dataset.

At the moment the API is still undocumented and evolving. The Client already communicates with the Engine through it, and technically anyone can query the Engine at:

engine.peertube-browser.com

There are a few endpoints available that return data, although they are still experimental and will likely change as the system develops. The plan is to gradually expand and stabilize this API so it becomes more flexible and useful for building additional tools, integrations, or alternative frontends.

Current work

Right now most of my work is focused on the development workflow, particularly how to work with AI agents inside the project.

As the project has grown, I started running into some limitations and practical problems when using agents for development. Because of that, I’m currently designing a workflow that helps structure this process better.

Part of this work also involves figuring out how to track and present development progress publicly on GitHub. I want to create a workflow that allows me to keep transparent records of development activity while also automating some repetitive parts of the process.

The goal is to optimize how I interact with AI agents during development and make it easier to show progress publicly as new features are implemented.

What’s next

I already have a rough plan for the functionality that should eventually be implemented. For now I’ll keep moving forward step by step following that plan.

Feedback from the previous post was very helpful, and I’m taking those comments and suggestions into account. If you have ideas, thoughts, or criticism — feel free to share them.

Support

At the moment the project is funded entirely by me. I’m building it not for personal use, but because I think it can be useful for others and because I genuinely enjoy working on it.

Also, to be honest, working on something meaningful helps keep my mind occupied during the war here in Ukraine.

If you find the project interesting or useful, and you want to support its development, I would really appreciate it. Seeing that people care about the project and use it is a huge motivation to continue working on it.

You can support the project in two ways:

• Patreon — for recurring support
• Donatello — a Ukrainian service that allows one-time donations directly to my Ukrainian bank account

Project's repo:

https://github.com/denikryt/PeerTube-browser

Any support, feedback, or ideas are very welcome.

Thanks for reading.

Hi there!

Just wanted to share the first lesson of my Blender video course. It is in Ukrainian, so if you ever wanted to learn Blender and practice Ukrainian this is your bingo :))

I’m going to post videos every week, there are 10 lessons in total. I will share them here as well.

Thank you for your attention :)

I’ve built a project called PeerTube Browser — a platform that aggregates videos from (almost) all PeerTube instances into a single interface.

The main idea is simple: improve discovery across the federated network. PeerTube is powerful, but finding interesting content across instances is still difficult. This project indexes videos and provides a custom recommendation system that I designed and implemented myself. It’s still evolving, but it already allows exploring content beyond a single instance’s local or federated feed.

At the moment, data is collected via a crawler and the public PeerTube APIs. Instances are filtered using the public whitelist from joinpeertube.org, plus several manual blocks to exclude unwanted content (pornography and other low‑quality or abusive material). The filtering approach is pragmatic and still evolving.

The project is still at an early stage.

The recommendation system is based on embedding vectors, ANN (approximate nearest neighbor) search, and user likes. All recommendation logic is executed server‑side. User likes are currently stored locally in the browser (localStorage), which allows generating personalized results without requiring account registration.

In the future, I plan to make the recommendation system user‑configurable — allowing people to influence how results are ranked and what signals are prioritized. One of the core goals is to implement direct ActivityPub support, so the system can receive up‑to‑date data from instances in a more native and federated way, instead of relying primarily on crawling wherever possible.

My goal is twofold:

• Help viewers discover videos they wouldn’t normally encounter. • Help creators improve visibility and overall discovery within the PeerTube ecosystem.

I have many ideas about how this system could evolve — especially around ranking, recommendation logic, and improving cross‑instance discovery — but before pushing further, I would really value feedback from people who actually use PeerTube.

If you’re interested, you can try it here:

https://peertube-browser.com/

Please test it and share your thoughts. What works? What feels wrong? What would make it genuinely useful for you?

Important note: the service is currently hosted on my personal workstation. I live in Ukraine, and due to electricity instability and the fact that I sometimes power down my machine, the site may occasionally be unavailable. At the moment I don’t have the resources to host it on a VPS or dedicated server.

Despite these limitations, I’m committed to developing the project further — especially if there’s real interest and constructive feedback from the community.

The project is open source. Repository:

https://github.com/denikryt/PeerTube-browser

For discussions, feature proposals, and deeper technical feedback, it would be most convenient for me to communicate via GitHub Discussions:

https://github.com/denikryt/PeerTube-browser/discussions

I invite anyone interested in the project to join the discussion there.

Thanks to anyone willing to test it and share their perspective.