Skip to content

build-in-public

When is SSO provided?

I had feedback from a user today after a recent post about exposing various app APIs without SSO, pointing out that that SSO was applied a little inconsistently across our apps. For example, Jellyseerr was exposed publically (it has strong auth and is used to share media requests), but Overseerr (of which Jellyseer is a fork) was not! 🤦

This is now fixed 👍

To clarify, here's how SSO is applied, based on the intended audience / purpose of an app:

  1. Apps that only you (the user) would use, are behind SSO without any native auth, where possible. This includes download clients, apps without auth (openbooks), Arrs, etc (although these can be optionally exposed to a limited degree)
  2. Apps which you might want to share (Plex, Navidrome, Kavita, Overseer, etc) and which provide their own trusted auth, are exposed without SSO, since their entire purpose is to share media / content with a wider audience than just yourself!

Our Elf-erral program, 10% for life!

Having a base platform nice and stable, we're now looking for more users, and one option I'm going to try is a referral ("elf-erral") program. The plan may be subject to change, depending on how the plugin / user flow actually works, but for now, here's the deal:

  1. Every user gets a unique referral URL, both on their "my account" page, and on every product page in the store.
  2. When a someone (not you!) uses your referal link, signs up, exhausts their free $10 ElfBuckz, and then tops up their ElfBuckz balance, you get 10% of all their future ElfBuckz top-ups. For life.

Given the minimum ElfBuckz top-up is $10, if you refer 10 users, you'll end up with at least $10 (10 x 10% of $10) credit to use for... buying more ElfBuckz! 💪

Beware exhausted ElfBuckz

Some users noticed today that their ElfBuckz balaces were exhausted, or near-to-exhausted. Currently, the system won't tell you if your ElfBuckz are running close to empty, it'll just tell you that your renewals failed, and leave you to figure out why!

I have a plan to send out notification emails re low balances, but for now, check in on your ElfBuckz balance occasionally to make sure you've got enough! You can also subscribe to a monthly ElfBuckz topup once you've got a handle on your expected usage requirements.

Added SSH Rclone mounts

We had our first request from a user wanting to mount data from a seedbox provider, in order to run an app not supported by that provider (Pyload). Consequently, we now have an SSH rclone mount product group for such a configuration. One interesting discovery was that the password submitted when you place the order needs to be an rclone obscured password (which is not really secure, since rclone can decode it again, but it prevents casual "shouldersurfing").

Approaching production

Although it's fairly arbitrary, July was our month of beta testing (June being "alpha", when things were only semi-working), and August will be our first month of "production". Most of the design questions are stabilized now (for example, BYO VPN for torrent clients, hardware transcoding, etc), the guts of the platform is now open-sourced, and it feels as if the next step is to increase the user base, in order to (a) fund the infrastructure, and (b) surface any further issues / improvements to be found.

Hardware Transcoding now available

Thanks to helpful elf-a-testers, we now have hardware transcoding support in Jellyfin, Emby, and Plex (PlexPass required).

Why is this a big deal?

Previously, the streamers would use CPU resources to transcode any media they deemed incompatible with your client. The only way to prevent one streamer hogging all the CPU was to apply a CPU limit (4 vCPUs) to each streamer, roughly tested to support up to 3 1080P CPU transcodes. This still places a heavy load on our nodes, given each node only has 16 CPUs. Oh, and 4K transcoding was just a total no-go, even with 4 vCPUs!

After enabling Intel QuickSync Video (QVS) transcoding in Jellyfin, I was able to transcode 4K HEVC media, consuming only 250m (¼ of a vCPU)1 Needless to say, this makes our platform a lot more scalable!

How well does it work?

I.. don't know. Plex has one lonely toggle which turns transcoding on/off, and Jellyfin has about 2 pages of advanced options which affect transcoding performance! It'll take a little trial-and-error to find the sweet spot per streamer, and it's impossible to test all variations / clients. So I've rolled transcoding support out to all (beta) users, and reduced the CPU allocation to the streamers to 500m (½ vCPU), so that CPU-based transcoding will fail. This may be a little extreme, but given we can now transcode 4K on ¼ vCPU, it's more transcoding grunt than we had previously.

It's likely that we'll refine the transcoding support / parameters over the next few days, so please feel free to play around, test, and send feedback in Discord.

Of course, as always, for optimal experience from your streamer, avoid any transcoding whatsover. (Direct-playing 4K media consumes 0.01 vCPU!s)

Read on for smaller announcements...

RIP ElfVPN

ElfVPN was a shared VPN which allowed the torrent clients (Deluge, qBittorrent, rutorrent) to be evaluated / used without having to bolt-on a BYO VPN subscription.

Shortly after we ramped up our test users from r/seedboxes, the VPS which ran ElfVPN was terminated by the provider for DMCA abuse.

After some consideration (details below), I've decided not to replace it, and instead withdrawn the ElfVPN products from the store.

TL;DR - From now on, in order to use the torrent clients, you will need to BYO VPN...

Passwordless logins FTW

A few weeks ago, I started looking into integrating our store / SSO login with OwnID, to solve the fact that when your SSO session times out, you have to re-sign into the store (also, in 2023, protecting all your services behind a simple password seems a little.. too little)

The development got stuck behind decomissioning longhorn (another long story, it didn't scale well!), but after finally reproducing the prod store in dev for an accurate bug report to the OwnID team.. it worked perfectly 🤦‍♂️

So... we now have passwordless / biometric logins for the store / SSO! 🥳

Health alerts, badges, GDrive & WebDAV

Just after I bragged yesterday about the increase in pod count, a bug in the webhook handler caused all subsequent orders to get stuck for ~10 hours! If you'd made a change to your subscription during that time, or signed up, you'd have been wondering where your apps went and why nothing provisioned 🤦‍♂️

Here's what this looked like...

Prometheus graph showing pod count with a 10h plateu indicating webhook failure

I squished the bug and hardened the webhook receiver, then tried to process all the backlogged orders. If you received a few duplicate confirmations this morning, that'll be why. If you placed an order and didn't receive it, try cancelling and then resuming the order to force the update.

Health Alerts

What I didn't expect is how many users would sign up for service and not jump into Discord, or get in touch when things didn't work. Discord makes announcmements / updates so easy, that I realized I hadn't invested enough effort into other communications channels, like email (an emailed welcome on purchase is still on the to-do-asap list)

Since we're still at beta-level stability, and I don't want a reputation for being unreliable, I wanted a way to alert users to changes to their apps' health - I discovered that we can do this with our existing health dashboard (using Gatus), by enabling email alerting. After a brief poll of the #elf-friends channel, I've now turned this on, so if you've got any unhealthy apps (and there are a few still), you'll get one email after 20m of downtime, and one email upon recovery.

Here's what the email looks like...