boringproxy VS cloudflared

boringproxy - Designed to be very easy to use. No config files. Clients can be remote-controlled through a simple WebUI and/or REST API on the server.

A couple of years ago I've read about this concept (already forgot the name) of using self hosted data storage with cloud applications. Basically, you as a user own your data and only permit the cloud hosted web application to access it - not own it and manage in your place.

I was thinking of a similar concept, but in the context of mobile applications. The mobile application itself would be accessible via Google Play Store/App Store, but the backend part would be self hosted and upon opening the application you would have to specify how to access backend.

My question is how would I access the backend if it was hosted on let's say rpi running in the living room? It's not a problem as long as I'm within the home network, but I want seemless network transition without losing access when entering/leaving the house. I was told https://www.cloudflare.com/en-gb/products/zero-trust/access/ could be used for this, but to me it sounds a bit of an overkill to use it for an application which would never be used by more than a single digit amount of users. This looks more suitable: https://github.com/boringproxy/boringproxy

Finally, someone in the above project's Matrix room directed me towards boringproxy - https://github.com/boringproxy/boringproxy. This was the perfect solution. No lengthy config files, easy to use and automate. Setup took about an hour and now everything is back up and running. The only issue I've currently not been able to solve is one where the container seems to use a websocket, which keeps getting timed out (will investigate this further tomorrow).

boringproxy (GitHub) is my go-to for this sort of thing. Thanks for the announcement, I'll have to do a head-to-head and see how they stack up!

boringproxy

Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with <100 users. These programs need a small amount of state for things like tokens, users accounts, and maybe a bit of domain-specific things. This can all live in memory, but needs to be persisted to disk on writes. I've reached for SQLite several times, and always come back to just keeping a struct of hashmaps[1] in memory and dumping JSON to disk. It's worked great for my needs.

Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to exist? Why can't everyone be on a federated server with state that fits in memory/JSON? I guess that's more of a philosophical question about big tech. But I think it's interesting that most of our tech stack choices are driven by projects designed to work at a scale most of us will never need, and maybe nobody needs.

[0]: https://boringproxy.io/

[1]: https://github.com/boringproxy/boringproxy/blob/master/datab...

This is the commit that seems to have broken the docker image.

I use https://github.com/boringproxy/boringproxy

cloudflared - Exposes local servers to the public internet over secure tunnels

Cloudflare Tunnel - Excellent free option. Nicely integrates tunneling with the rest of Cloudflare's products, which include DNS and auto HTTPS. Client source code is Apache 2.0 licensed and written in Golang.

I run a RaspberryPi 3 with FreeBSD 13 booting off an SD card and a USB SSD for storage [1]. Coincidentally today (1/7/2024) is its one year anniversary.

It runs a jail with my single user GotoSocial ActivityPub server [2] reasonably well with cloudflared [3] handling incoming traffic and acting as CDN to take some of the load. Originally it was only using an SD card, but there was too much IO contention so a USB-SSD adapter is used to offload the IO.

I choose FreeBSD over Linux since I have other Rpis with Linux already and wanted more experience with *BSD, jails, and ZFS. Unfortunately ZFS wasn't the best choice on an Rpi since it's more cpu intensive and switched back to UFS.

Overall it's been solid, multiple GTS updates and have it on my list to update to FreedBSD 14 but not really in a rush.

1. https://social.ecliptik.com/@micheal/statuses/01GP860MYM2CGH...

2. https://gotosocial.org/

3. https://github.com/cloudflare/cloudflared

# Install apt dependencies !apt install dotnet-sdk-7.0 git # Install Clouldflared (not on apt) !wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb !dpkg -i cloudflared-linux-amd64.deb # Download StableSwarmUI !git clone https://github.com/Stability-AI/StableSwarmUI # Download ComfyUI backend %cd /content/StableSwarmUI !mkdir /content/StableSwarmUI/dlbackend %cd /content/StableSwarmUI/dlbackend !git clone https://github.com/comfyanonymous/ComfyUI %cd /content/StableSwarmUI/dlbackend/ComfyUI # Setup ComfyUI !pip install -r requirements.txt

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb && sudo dpkg -i cloudflared.deb && sudo systemctl restart cloudflared

Something like cloudflared would be awesome. https://github.com/cloudflare/cloudflared

if you're on windows, you can install it with the exe: https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64.exe (or https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-386.exe if your using 32bit windows.)

So, the "more than one" issue is kind of discussed HERE and HERE but for sure, for whatever reason, this caused me sleepless nights.

%cd /content/naifu !pip install virtualenv && bash ./setup.sh !curl -Ls https://github.com/ekzhang/bore/releases/download/v0.4.0/bore-v0.4.0-x86_64-unknown-linux-musl.tar.gz | tar zx -C /usr/bin !curl -Lo /usr/bin/cloudflared https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 && chmod +x /usr/bin/cloudflared !/content/naifu/venv/bin/python -m pip install -qq pytorch_lightning==1.7.7

Anyway, here is the Github link for Cloudflared (aka Cloudflare Tunnel client) which should allow you to remotely tunnel into your Synology server instead of using the HTTP-based reverse proxying method: https://github.com/cloudflare/cloudflared