Welcome to our container images, if looking for a container start by browsing the container packages.
The goal of this project is to support semantically versioned, rootless, and multiple architecture containers for various applications.
We also try to adhere to a KISS principle, logging to stdout, one process per container, no s6-overlay and all images are built on top of Alpine or Ubuntu.
In most cases if the application developers supports a container image and adheres to the above I will often not build a custom image and use their image instead.
The containers built here do not use immutable tags, as least not in the more common way you have seen from linuxserver.io or Bitnami.
We take do take a similar approach but instead of appending a -ls69 or -r420 prefix to the tag we instead insist on pinning to the sha256 digest of the image, while this is not as pretty it is just as functional in making the images immutable.
| Container | Immutable |
|---|---|
ghcr.io/elfhosted/sonarr:rolling |
❌ |
ghcr.io/elfhosted/sonarr:3.0.8.1507 |
❌ |
ghcr.io/elfhosted/sonarr:rolling@sha256:8053... |
✅ |
ghcr.io/elfhosted/sonarr:3.0.8.1507@sha256:8053... |
✅ |
If pinning an image to the sha256 digest, tools like Renovate support updating the container on a digest or application version change.
Some applications do not support defining configuration via environment variables and instead only allow certain config to be set in the command line arguments for the app. To circumvent this, for applications that have an entrypoint.sh read below.
-
First read the Kubernetes docs on defining command and arguments for a Container.
-
Look up the documentation for the application and find a argument you would like to set.
-
Set the argument in the
argssection, be sure to includeentrypoint.shas the first arg and any application specific arguments thereafter.args: - /entrypoint.sh - --port - "8080"
For applications that need to have persistent configuration data the config volume is hardcoded to /config inside the container. This is not able to be changed in most cases.
-
Get familiar with the structure of the repositroy
-
Find a similar application in the apps directory
-
Copy & Paste an application and update the directory name
-
Update
metadata.json,Dockerfile,ci/latest.sh,ci/goss.yamland make it suit the application build -
Include any additional files if required
-
Use Taskfile to build and test your image
task APP=sonarr CHANNEL=main test
Here's an example of how tags are created in the GitHub workflows, be careful with metadata.json as it does affect the outcome of how the tags will be created when the application is built.
| Application | Channel | Stable | Base | Generated Tag |
|---|---|---|---|---|
ubuntu |
focal |
true |
true |
ubuntu:focal-rolling |
ubuntu |
focal |
true |
true |
ubuntu:focal-19880312 |
alpine |
3.16 |
true |
true |
alpine:rolling |
alpine |
3.16 |
true |
true |
alpine:3.16.0 |
sonarr |
develop |
false |
false |
sonarr-develop:3.0.8.1538 |
sonarr |
develop |
false |
false |
sonarr-develop:rolling |
sonarr |
main |
true |
false |
sonarr:3.0.8.1507 |
sonarr |
main |
true |
false |
sonarr:rolling |
A lot of inspiration and ideas are thanks to the hard work of hotio.dev and linuxserver.io contributors.