Add a Dockerfile and a GitHub Actions workflow for testing it

[villapx]

To promote easy self-hosting, I wrote this Dockerfile that builds and packages the application into a container image.

I also wrote a GitHub Actions workflow that builds the image, runs a container and checks its health.
This workflow will succeed once the container becomes Healthy. Since we are leaving the HEALTHCHECK configuration largely at its defaults, this should succeed 30 seconds after the container is started since --interval is being left at its default value of 30 seconds. If the nginx web server fails to come up, this workflow will fail in at most ~90 seconds (--interval=30, --retries=3) because the container's Status will change to "unhealthy" and thus fail the if-check in the workflow.

This image could next be published to Docker Hub, but perhaps that can be a separate PR, since it presumably will require a secret to be added to the GitHub repo.

[Volcomix]

Thanks for the contribution @villapx, the changes themselves look solid and well put together 👍

Before going further, I’d like to better understand the underlying motivation behind this PR. Could you elaborate on the concrete problem or use case you’re trying to address, and why you believe an additional self-hosting option should exist for Recorder?

In particular, when you mention potentially publishing the image to Docker Hub, my understanding is that this would allow people to deploy Recorder on their own infrastructure, running the exact same version of the app that is already available, while it still functions in the browser in exactly the same way (fully client-side), without needing to check or build the code themselves. The main difference being that it would be served from a different origin than the current hosted version.

I want to make sure I clearly understand the practical value this brings for users before assessing whether this fits the project’s scope and long-term maintenance goals.

[villapx]

@Volcomix Happy New Year! My apologies for the delay; I've been pretty unplugged since I submitted this PR right before the holidays.

You're correct in your understanding. Offering a Dockerfile (as well as, potentially, a published Docker image) increases the user's freedom by providing a self-hosting option. Additionally, maintaining the Dockerfile right here in the source repo prevents users who want to self-host from needing to maintain their own.

Personally, I am running this application on my local server and publishing it to my Tailnet, so that my family members and I can use the app on our own, way-overpowered, vastly-underutilized infrastructure. More so than anything else, it's just fun to self-host, but also it's nice that we can run applications locally and share them amongst our family and friend group on a relatively "reserved" set of infrastructure. For example, if an AWS region has an outage or congestion, that will very likely have no effect on our family's ability to access our self-hosted applications.

Cheers!

P.S. - I love your app, I use it both at work and at home all the time.

[Volcomix]

Thank you for taking the time to explain.

I was mostly viewing Recorder from the perspective of a deployed app for which we also provide the source code, whereas your PR highlights a different and valid angle: source code that people can operate themselves, with the current hosted version effectively acting as a demo of that code running. Keeping a Dockerfile in-repo lowers the barrier and avoids fragmented, user-maintained solutions.

I’m going ahead and merging the PR. Thanks again for the contribution and for the kind words about the app, much appreciated! 😊