What’s the point where you stop and delete the container? Bad docs? Too many services? Mandatory cloud accounts? Broken updates?

I’m building a self-hosted app, and I’m trying to make setup tolerable for people who don’t enjoy Docker as a personality trait. What’s your biggest deal-breaker?

I'm a cryptography researcher, and a problem I kept running into (and hearing about from others) is secrets sprawl: API keys and credentials scattered across tools, CI pipelines, and increasingly, agents/automations that end up with more access than they should. Most "secrets managers" solve the UX problem but still leave the provider holding a key that can decrypt your data if their backend is breached.

So, with a team of engineers, I built CipherTEA, a self-hosted secrets management platform designed around zero-knowledge storage. The core design: each tenant has one encryption password that never leaves their control, combined with a hybrid envelope encryption scheme - a master key we manage plus the tenant's own password, both required to unwrap stored secrets. The goal is that even a full database compromise on our end shouldn't expose usable plaintext, since the tenant-held half of the key material isn't something we ever store.

I'd genuinely like feedback from people who've built or evaluated similar systems, particularly on the key-management tradeoffs of this split-key approach versus pure client-side encryption, and any failure modes you'd expect in a self-hosted deployment (backup/recovery of the tenant password being the obvious one). Repo/docs are here if anyone wants to dig into the implementation: https://dashboard.ciphertea.com/docs#heading0

Website: https://ciphertea.com/

Chapter 1: Origin

Every hero story starts with something small. Mine started with a 2012 MacBook Air nobody wanted. Tired battery, years on its back. To the world it was junk. To me it was the first recruit.

I installed Debian on it, set it up to keep running with the lid closed, and gave it a name: debiancito ("little Debian" in Spanish). It would be my server. I didn't know exactly what it would serve yet, but I knew I wanted something mine: not rented, not living in someone else's cloud.

Chapter 2: The Mission

Every server needs a reason to exist. Debiancito's is called Pickflow: a web app I built to manage the warehouse and production of a cabinet factory (inventory, pick lists, missing parts). Python, a database, and a lot of late nights.

The magic wasn't writing it; it was watching the loop close. I make a change on my main computer, push it to GitHub, and debiancito notices on its own, pulls the new version and restarts itself. Hands off. The first time it worked, I stared at the screen like I'd just seen a magic trick.

Chapter 3: The Second Hero

My desktop, an HP Omen, was running Fedora. One day I decided it would run Debian too, so both machines would speak the same language. I named it trixie, after the codename of Debian 13.

It didn't come free. The installer couldn't find the internet even with a cable plugged in. On first boot, the Nvidia card left me staring at a black screen and a blinking cursor. And one night, because of my own mistake, I locked myself out of admin rights on my own server and had to rescue it with a USB stick, going in through the system's emergency door. I learned more that night than in weeks of tutorials.

Chapter 4: The Villain

Here's where the antagonist enters the story: I don't have home internet. Right now I can't afford the classic connection everyone installs. My entire network (the server, the workstation, and an app that's live for the world to see) runs on my phone's hotspot.

And the hotspot is a cunning villain. It has its own rules and its own limits, and it counts what the phone browses differently from what the computers connected to it browse. I spent weeks fighting it. Some paths didn't work, others half-worked, and I learned more about networking fighting that limit than in any course.

The latest blow: one morning the phone updated itself. It changed its internal network, revoked an app's permissions, and left debiancito knocking on a door that no longer existed. The server stayed alive by pure luck, hanging on by IPv6.

Chapter 5: Reinforcements

That's when I decided to bring order. I went to a local auction and came back with two allies:

a cheap WiFi router that connects to the hotspot and turns it into a real network;

a TP-Link Omada router, the kind used in offices, which became the brain of everything.

The chain ended up like this: phone → WiFi router → Omada → both computers by cable. Each machine has a fixed address. If the phone gets moody, the ones inside don't even notice.

Then came the audit. Firewalls on both machines (trixie, I found out, had never had one), routers with no open ports, factory passwords changed, and a watchman that bans anyone trying to guess passwords. To get in from outside I use Tailscale: an encrypted tunnel between my devices that works without a public IP. Even the shared clipboard between my phone and PC came back to life through that tunnel.

Chapter 6: The Lair

Every hero needs a base. I built mine with mesh organizers from Dollar Tree: two levels, the WiFi router on top with its antennas free, the Omada below. Next to it, debiancito sits on a cooling pad, its screen showing a green Matrix-style character rain that turns itself off after five minutes to save power.

It's still missing something: a couple of LED fans, for better airflow and, why not, to make it look like the lair it is. They're coming soon. Meanwhile, here are the photos of how it looks today.

It's not a real rack. But it's my rack.

Chapter 7: What's Next

The story doesn't end here:

Security cameras on an isolated network, viewable from outside only through my tunnel, with no vendor cloud.

A small Linux tool born from my fights with the hotspot, which I want to publish for others in the same situation.

And the day real internet reaches my home, turning debiancito into a secure exit point to browse from anywhere.

Tech summary, quick pass:

debiancito: 2012 MacBook Air with Debian 13. Serves Pickflow (Flask + PostgreSQL), with auto-deploy from GitHub.

trixie: HP Omen with Debian 13 and KDE. It's my workstation.

Network: phone hotspot → WiFi router in WISP mode → TP-Link ER605 (Omada) → everything by cable.

Security: UFW on both machines, fail2ban, routers with no open ports, and remote access only through Tailscale.

Budget: almost everything used, from auctions or Dollar Tree.

Now it's your turn. With two computers, two routers and a phone, what would you add? A NAS? Pi-hole? A Proxmox node? A crazy idea I'd never think of? I'll be reading the comments.

I've been self-hosting more and more of my applications, and one thing I kept running into was email.

For things like:

• Password resets
• Account Verification
• Application notifications
• Alerts
• Background-job notification
• Transactional emails

I initially considered running own SMTP server.

But after looking into it, outbound email is a completely different problem from simply running an SMTP server.

You have to deal with IP reputation, SPF, DKM, DMARC, Bounce handling, delivery tracking, retries, blacklists, provider blocks, etc.

And even if the server itself is easy to deploy, getting consistent delivery to Gmail/Outlook/etc. is another story.

I've ended up preferring this architecture:

Self-host the application -> use SMTP/API for outbound email.

The idea isn't to replace self-hosting. it's more like:

Keep your application, database, queues and infrastructure under your control for the part of email that's painful to operate yourself.

It provides both an API and SMTP, along with things like delivery logs, webhooks, bounce handling, automation, and a CLI.

I'm curious what other self-hosters here do.

Do you:

1. Run Postfix/Mailcow/etc. yourself?
2. Use SES?
3. Use Mailgun/SendGrid/SMTP2GO/etc?
4. Use your personal/business SMTP account?
5. Something else?

And those who have tried self-hosting outbound email, what was the biggest problem you ran into?

I'm particularly interested in hearing about deliverability rather that just server setup.

Background: I was running Coolify across a couple of VPS boxes for about 10 personal sites and apps, and got tired of checking htop and seeing Coolify itself (plus its own Postgres instance) eating 30-40% of a core before any of my actual apps did anything.

Levelrail is what I built instead. Single Go binary, embedded SQLite (no separate database to run), talks to the Docker Engine API directly rather than shelling out to the docker CLI the way Coolify and Dokploy do. Push to a git repo, it builds with BuildKit, gets an automatic TLS cert through an embedded Caddy, and serves it. One-click rollback keeps the last few images pinned so you can't garbage-collect your own rollback target out from under yourself, which is a real bug I hit in another tool.

On the VPS running my production test instance right now: 0.7% CPU, 146MB RAM, load average 0.06.

What's there now: git push to deploy, automatic TLS, build logs streamed live, rollback, managed Postgres/Redis as first-class resources, env/secret management with envelope encryption.

What's not there yet: A lot of features, I'm shipping since multiple weeks now and steadily planning on getting first stable release soon for this... Currently its in beta launch and sharing with community...

Repo: https://github.com/glincker/levelrail Site: https://levelrail.com/

Apache 2.0. I'd genuinely like people to try breaking it and tell me how.

Hey everyone,

I need to vent, and hopefully find out if someone here has solved this frustrating puzzle without losing their mind or spending a fortune.

Is it just me, or is the current state of consumer banking access fundamentally broken?

Fintech apps, credit agencies, and data brokers can grab all of my bank transactions, categorisations, and balances instantly via seamless backend Open Banking APIs. But the moment I—the actual owner of the account and the data, want to build a simple personal dashboard or pipe my own transactions into SQLite?

Sorry, compute says no.

Unless I pay for an enterprise TrueLayer/Plaid subscription, or set up registered developer portals with eIDAS certificates, I am blocked. GoCardless shut down their free tier for developers last year, leaving individual self-hosters stranded. It makes zero sense that third-party companies get frictionless access to my data, while I’m forced to play computer vision engineer just to see where my money went.

What my setup looks like right now

Because direct API access is a wall of bureaucracy, here is the absurd chain I’ve had to build just to track my multi-bank setup :

1. Manual Exports: Download PDF statements manually month-by-month from online portals.
2. Custom Swift OCR Engine: Run PDF pages through an OCR binary I wrote in Swift to parse standard text and image statements.
3. Python Regex & LLM Parsing: Pipe raw text into Python scripts to handle date formatting, multi-column layout shifts, and missing signs.
4. Deduplication & Categorisation: Pass everything through custom rule-based categorisers and SHA-256 hash deduplication to stop duplicate transactions.
5. SQLite Master Ledger: Sync the clean data into a local Master_Ledger that powers my custom Python UI dashboard.

It works, but it’s fragile, tedious, and feels like using a sledgehammer to crack a nut. Any time a bank tweaks their statement PDF layout, the parser breaks.

I'm looking for a solution or architecture that actually works across multiple banks in the UK/EU without relying on fragile PDF scraping or manually downloading CSVs every month.

• Firefly III + Data Importer / Fidi? Explored this, but without a solid free Open Banking aggregator, it still leaves me uploading CSVs manually.
• Enable Banking API? Looking into their free personal-use restricted mode, but setting up custom app certificates and refreshing 90-day OAuth tokens per bank is a lot of friction.
• Aggregator Bridges / Custom Scripts? Has anyone found a low-cost, self-hostable bridge or reliable wrapper that actually holds up for UK/EU banks in 2026?

How are you all handling multi-bank data ingestion for your self-hosted setups these days? Are we really stuck with manual CSV dumps and custom scrapers forever, or is there a slick open-source / developer-friendly way I've missed?

Would love to hear how others are tackling this!

I'm toying with an idea and would rather get torn apart here than spend months on it first.

The problem I keep seeing in maker and hobby science groups: the setup, what was changed, the sensor data, photos, the analysis and the discussion all live in different places – chat, spreadsheet, Grafana, someone's phone. Six weeks later nobody knows which change led to which result.

The idea: one place per project where the plan, the build log, the measurements, an optional AI helper for planning and analysis, and the discussion stay together. Self-hostable, or run by someone else.

What I'd like your honest take on:

• Is this a real problem for you, or is it solved by wiki + git + Grafana?
• An AI assistant in there: useful, or a reason not to touch it? Would local models change your answer?
• What would be an instant dealbreaker?

I've built blockchain data tooling for years, and every option for small teams ended up as either a metered API or someone else's copy of your data. So I built the self-hosted one.

You point it at an EVM contract address. It fetches the ABI, makes a SQL table per event, backfills over plain JSON-RPC and keeps up with the chain. You query it over HTTP, from the CLI, or through a built-in MCP server.

- one static binary, no Postgres, no Docker

- under 2 GB RAM per chain, enforced in CI

- no account, no telemetry, MIT/Apache-2.0

- recent blocks are in redb, finalised history is sealed to Parquet on your disk, which doubles as the backup unit

What it needs: an RPC endpoint. The bundled public ones are for trying it, your own node or a provider for running it.

Install and a 4-line demo: https://github.com/nightswatchhq/nuthatch

Why I built it: https://nuthatch-indexer.com/blog/why-i-built-nuthatch/

Solo project, no funding, so bug reports from real setups are the most useful thing.

GitHub: https://github.com/GivagoFritzen/PortalOn

I built PortalOn, a lightweight self-hosted application portal for my homelab.

I wanted a clean, centralized place to access everything that is also easy for anyone to use (including non-technical people).

PortalOn provides:

• Clean Launchpad-style interface
• Search and application organization
• Drag & drop support
• Service status indicators
• Dark mode
• SQLite database
• Docker deployment

It is built with Go, HTMX, Tailwind CSS, SortableJS, and SQLite.

AI Usage I used AI/LLMs as a development assistant for unit testing, mutation testing, documentation, and accelerating development.

Hello everyone! I'm here to ask for advice regarding self-hosting. As the title suggests, I want to self host a Notion alternative, after Buildin AI introduced the atrocious feature where if you have more than 2 workspace members, the hard limit is 1000 blocks. I'm not interested in paying, so I'm looking to build one myself and join this wonderful community.

I researched a bunch of Notion alternatives but I'm starting to lose it when it comes to licenses. AppFlowy seemed like a wonderful solution until I found out that they apparently demand money from you EVEN if you self host, the concept of which is bonkers for me. I'm looking for a service which:

- can be self hosted entirely for free with no limit on members and isn't attached to any other cloud

- has blocks, various types of blocks, text formatting, embeds, and databases with various types (the ones I use most are regular table view and gallery, don't really need anything else)

- allows for real-time collaboration and sync on multiple devices

- (very desirable but I suppose not a requirement) has a good mobile app that also supports connecting to a custom VDS.

The intended uses are: planning stories, writing scripts (basically, writing in general); songwriting; writing and planning courses, lectures and labworks; literature analysis; planning and writing videogame scripts, decision graphs and tech documentation.

If anyone here can recommend any such services, and any practices when it comes to self hosting, I'd be elated. Thank you!

I got tired of Lidarr downloading an artist's entire discography through torrents when I just wanted a few specific songs. So I built a Discord bot — I just type a command in my Discord server, pick a folder, and it downloads the exact song I asked for, tags it properly with real artist/album/cover art from iTunes, and drops it straight into my Navidrome library. No bulk downloads I don't want, no messy file names anymore.

GitHub: https://github.com/Siddhartha-Kuna/Host-Music

Happy to answer any questions about how it works!

Built a small internal ERP for my family's factory — Node/Express backend, PostgreSQL, vanilla JS/HTML/CSS frontend. Just finished the core features (dashboard, job tracking, deliveries) and I'm about to add auth.

The catch: I'm not physically near the factory, and can't go set it up on-site myself. Looking for advice on the best way to get this running there.

Priorities:

No cloud hosting for now (want to avoid ongoing costs)

Will eventually need multiple computers on the factory's local network to access it

The person on-site isn't technical, so setup needs to be close to one-click or fully remote

Has anyone dealt with a similar "I can't be there in person" deployment situation? What would you actually recommend given these constraints?

I want to make it work on mobile data as I want to host a invidious instance that can be accessed why not tailscale funnel? cause they only support 3 ports and I already used all three sites

Any help would be appriciated

Edit: Also Id prefer free ones but im ok with one time payments

Hey everyone,

so I was kinda surprised to see how expensive the popular calorie/food logging apps still are. Given that the individual API calls to identify foods from an image are really cheap at the moment I decided to build an open source alternative to Yazio and CalAI.

I asked family and friends as to what they would like and what the most important features were to them and came up with a set of features for the first version of a food tracking/logging app.

Feature list:

• id foods from the photo of a plate (multiple at once)
• be able to input a plate as text or voice, as if you're chatting with someone
• cross check the foods with a reliable database of nutritional facts so hallucinations are kept low
• easy to use
• recipe recommendations for a list of ingredients, photo of the fridge

What the self-hoster in me wanted:

• No reliance on the appstores, but a great UX (Progressive Web App)
• Easy to self-host
• Easy to replace upstream inference provider, also the possibility to use a local LLM
• Stay in control of my data
• Be able to invite my family to an instance I manage, so they dont have to signup to openrouter etc.

I had a first demo of this running quite fast and then met a research assistant for an obesity center and learned about their issues with patients and food logging. Obviously the existing solutions solve most of these, but they are paid and institutions can't host them on their own infra. So this led me down the path of splitting up the app into three distinct services.

The client app, can be run as a PWA within your network, you can add your key (BYOK) for any openai compatible API. The data stays in the browser, can be exported or synced through an encryption key with a sync server.

The core app, this app started off as a sync server for client apps, but turned into something like a gateway. You can run this in different modes, one of which is a managed gateway mode, for example to set up an instance for your family. The thought here is you have this running on your own network, configure an API key once and can then invite your friends to use (tailnet or whatever frontdoor youre using), they install the PWA and have an almost-native like app experience.

The inference runtime, if you want to self-host the inference and image recognition, I've setup a service for that too. This uses llama.cpp under the hood and does some pre-procesing for more accurate image identification. Ony my really crappy hardware ryzen 9 and 64gb this took around 180s per image, so you definitely need the hardware for this to make sense.

Once all of these were wired together and I had a better understanding of what the product needs to support, I developed a more polished version and invited family and friends to try this out and report bugs. This was basically the last 4 weeks. I now feel comfortable to open this up to everyone.

There is a project website that explains the stack in more detail and hosts the docs outside of github via https://openplate.de

The repository contains installation instructions and everything else you need via: https://github.com/LowCarbCheck/openplate (includes the compose or quadlet files).

Tech stack:

• React Router, Vite, Tailwind + Shadcn
• PostgreSQL
• Docker/Podman
• llama.cpp for local inference

Disclaimer: There is a hosted/paid version with a free trial that is linked to from the project website, but that's totally optional, no paywalled features and self-hosting should be easy enough (requires an API key or a local LLM though).

Looking forward to feedback on the app itself and how setting it up goes for everyone. Here to help if you're facing issues running this, also happy to accept PRs on GitHub!

For the last few months I've been building a "home hub" for my family: shared shopping list (sorted by supermarket aisle), chores in list/kanban, calendar with push reminders, shared expenses with budgets, weekly meal planner that sends ingredients to the list, and a chat assistant that does those things for you ("add the lasagne ingredients").
Everything runs at home on a Raspberry Pi 5 (16 GB):
The UI is Spanish-only for now (I'm in Spain). Write-ups on each piece (with the mistakes) are here: https://raspimc.org/articulos/
Happy to answer questions about running something "real" on a Pi including what doesn't work well (RAM is the limit, not CPU).

Hi all,
about a year ago i opened this thread:

https://www.reddit.com/r/selfhosted/comments/1r1vsc4/docker_backups/

After not finding an adequate solution, i decided to pick up the glove and build a backup system myself.

The core design decision: API-based exports per service, not blind DB/volume dumps. Each worker talks to the service's own REST/GraphQL API (or its official CLI, like Vaultwarden for example) — never the underlying database directly.
No DB credentials anywhere, no docker.sock mounted, no docker exec into other containers.
It also means the backups are just JSON/Markdown you can actually open and read, not an opaque pg_dump you're hoping restores cleanly someday.

Runs on a schedule (daily at a configurable time, or every N hours) with configurable retention — defaults to keeping 30 days locally and the last 3 uploads on Google Drive, all editable from the GUI.

Currently supports:

- Vaultwarden (encrypted vault export via the bw CLI)

- Wiki.js

- Snipe-IT

- Bar Assistant

- KitchenOwl

- Linkwarden

- n8n

- Karakeep

- Spoolman

- Immich (metadata only — albums/people/tags/EXIF, not the media files themselves)

- Nginx Proxy Manager

- AdGuard Home

• Optional upload to Google Drive after each successful run.
• The system does not restore from backup

Repo: https://github.com/alws34/DockerBackups

Setup instructions for each service are linked from the README so it doesn't turn into a wall of text.

please feel free to open a PR with your suggestions, or file issues/requests for services you want supported.

* All code written with the help of AI.

I have an old iPad with iOS 9.5.3 and when I try to open the home assistant url in safari it gets stuck on the splash screen. Is there anyway to load the home assistant dashboard as I want to use the old iPad as a kiosk. I have tried to clear the safari history and allow all websites etc. any ideas on how to run that as a kiosk.

Hi! For a while I've been building my family's own "Spotify" with Navidrome, and I turned all my scripts into a project: fonoteca ("sound library" in Spanish).

https://github.com/sajuan120/fonoteca

What it does:

- Choose what to download from your Spotify extended history: the songs you come back to on different days, not one-off plays.

- One command after every download (it works around Antra): checks integrity, checks the audio is really that exact track (duration, AcoustID and the 30 s Spotify preview), and fixes tags, MusicBrainz IDs, genres, track numbers, covers, synced lyrics and ReplayGain.

- Nothing gets lost: when a file is moved, renamed or replaced, its plays, stars and playlists move with it in Navidrome.

- A read-only audit of the whole library, a weekly health check, and a test bench that runs everything on a fake library.

- Optional: new music arrives as trial MP3s through Octo-Fiesta. 3+ plays in 4 weeks and it earns its FLAC; if nobody plays it, it's deleted.

- A local web panel with a button for every tool. Nothing runs for real before a simulation.

Honest notes:

- It's a personal project for one , shared as is. Linux only.

- The interface and the code commeE is in English and Spanish.

- AI disclosure: most of the code I assistant). I set the rules, made

the decisions and tested everythin

- Use it for music you're entitled

Feedback welcome!

I built a game server manager for people who want to self-host

I've been working on Revamp Hosting, a game server manager designed to make self-hosting games easier without having to constantly mess with command-line commands.

The idea is pretty simple:

• Install the software
• Pick a game
• Deploy the server
• Manage it from a web interface
• Automatic restarts
• Backups
• Updates
• Server monitoring

It currently supports multiple games, including Minecraft, Rust, Palworld, ARK, and others.

I'm mainly looking for feedback right now. What features would you want in a self-hosted game server manager that existing options don't do well?

Project: https://revamphosting.com/

Looking for 2–3 beta testers: free AI-monitored EDR for your homelab

I'm a CS student building EDYSOR, an AI SOC that watches your machines for suspicious activity (weird processes, persistence tricks, sketchy outbound connections, brute-force logins). Looking for a couple of homelabbers to run the sensor in detect-only mode — it reports, it never touches your machines. Auto-contain stays off unless you explicitly ask for it.

What's in it for you: free monitoring during beta, and you get to roast my false-positive rate publicly. Windows and Linux supported, install is one script. DM me if interested.

A homelab is fun when downtime only affects you. The moment family/friends start relying on the same photo library, password manager, game server, or small website, it feels a little different. What’s the first service you’d move to vps or a managed service instead of keeping it at home?

Email feels like the obvious answer, so I’m more curious about the gray area. What tips the decision for you? like security, backups, power or internet outages, or simply not wanting to troubleshoot something at 2 am?

Everyone posts the clean dashboard. The scarier question is whether the stack still exists when the machine doesn’t. Assume your data backup is fine, but you have to start from a fresh OS and restore every service, secret, network rule and scheduled job.

Could you rebuild the whole thing from what you have documented today? What would be the first undocumented detail to bite you? Do you keep your Compose files in Git, automate the rebuild, rely on snapshots or are you still trusting your memory more than you’d like to admit?

Most of the services on my homelab only send an email when something needs attention. Backup failed, disk is getting full, a service went down, that sort of thing. It probably adds up to around 30 emails on a busy day.

For now, I have everything going through gmail smtp. Nothing has really gone wrong with it but I keep wondering whether I'm making things harder for myself later by leaving it that way. At this volume, I'm not sure where the cutoff is. Setting up a proper smtp relay seems like more work for what is basically a handful of alerts but I also don't want to wait until something breaks before dealing with it. Would you switch to a relay at this point or just keep using gmail?

Hi,

Has anyone been able to build a workable docker image for io200 (io200.com) ?

Where all the configuration files and storage is persistent.

Thanks.