Immich is fantastic. Been using it for over a year on Unraid (which is mostly 1-click setup).

On the media streaming front, Jellyfin tends to be a great option. Very similar to Plex, but without the ‘is it cloud or not’ quirks (not to mention it has no paid-for extras).

I'm not sure it can replace my custom user-scripts on Unraid yet, because for appdata specifically, you'd generally want to make sure affected containers and VM's are stopped.

However, I could see it being useful for 'assets' (e.g. documents, media, etc).

It's designed to solve very specific problems:

- Wait times
- Regulatory requirements for on-prem building

It's essentially a wrapper around EAS CLI, so most of the technical issues you might come across can be solved in the same way as you'd solve them with a local EAS CLI install.

It doesn't bypass any build requirements (e.g. you still need an Apple system for iOS builds).

You still need the build tools (e.g. xcode, fastlane) installed.

The goal here is to enable on-prem building without it relying on 'some developers laptop'.

As stated before, this isn't going to be a commercial offering.

You still have to buy and manage the hardware. It still relies on EAS for provisioning.

It still requires your project to be correctly configured (e.g. dist certs provisioned via EAS).

I still don't know when this project will be 'ready' or even 'early alpha'. It's not a priority, but it's also not unimportant.

I decided to add a fresh Expo project to the repo and add Storybook to it.

My root folder consists of `expo`, `next`, and `stories`, so it's technically a monorepo, but it doesn't warrant the additional tooling because the only shared parts are the stories.

So, it's unlikely there'll be any results to share today due to a delivery delay with the Mac Mini. Guess we'll see on Monday.

(I could probably just use my Macbook to get results, but I'm keen to ensure it works on a completely fresh environment)

The thoughts and decisions of a new CEO are not often reflective of the values of an existing team.

The consumer-facing elements of a product don't take any of the good away from the things that happen in the 'background' by the technical teams.

I'm getting ahead of myself now though. Let's see how alpha testing of this flow goes and work from there.

Beyond this, I think having some sort of organisation of local builds would be beneficial. If things go well, then having a web UI for local builds might be beneficial.

And of course, running the server + client on your laptop is still an option to have the web UI for management.

I don't want to ever take business away from Expo of course, but I do recognise that many clients I've worked with (and myself) want builds asap, but don't have the money to throw at infra.

This is more of a personal efficiency solution.

I know that EAS use VM's on their cloud builders, so I'm thinking that they already know the answer to this.

The goal isn't to ever make this a commercial offering. If someone is spending £2000+ on a Mac mini with enough RAM and storage, then they've already done the investment I'd say.

I need to consider how well it might handle concurrent builds.

I'm not concerned with computing power, but whether the tools that lie underneath EAS CLI --local can actually run concurrently.

It might be a case that I need to look how to provision a Mac VM on the system to enable that.

Assuming testing goes well, phase 2 of this will be expanding the data that's available by adding some sort of database.

Since it's gonna run on a local server (and I'm pro-local), something like sqlite is probably a solid choice.

Phase 3 might be a web UI.

Alright, client alpha 1 is working too, so looks like we've got a working end-to-end flow.

Server runs via `yarn serve` (designed for local install and running with an env file), client runs via an npx command (designed to run with args from a project root directory), both part of the same package.

On one hand, yes.

On the other, people are already completely oblivious to anyone else around them when they decide to abruptly stop in a station concourse, and collectively, they inadvertently blockade people from getting past.

That, but at the station doors? Ooof. Hell no.