Photoprism Helm Chart

Helm chart to install PhotoPrism.

PhotoPrism is a server-based application for browsing, organizing, and sharing your personal photo collection.

TL;DR;

helm repo add p80n https://p80n.github.io/photoprism-helm/
helm install p80n/photoprism --set persistence=false

Introduction

This chart deploys PhotoPrism to your Kubernetes cluster. It's mostly based off the docker-compose file available at PhotoPrism's GitHub repository.

Kubernetes is great for running PhotoPrism since there are a lot of k8s tools available to enhance the experience:

Cert Manager makes it easy to put PhotoPrism behind SSL
Ingress makes it easy to expose PhotoPrism with actual URLs
If your reverse proxy supports it, you can add authentication (e.g., basic auth) to provide a bit of lockdown.
Running a database as a separate service helps with maintenance. Instead of figuring out what PhotoPrism database files need to be backed up, you just backup your MySQL database as you always would.

Installing the Chart

To install the chart with the release name my-release:

helm install p80n/photoprism --name my-release --namespace photoprism -f values.yaml

Configuration

The following table lists the configurable parameters of the Photoprism chart and their default values. It's worth noting that PhotoPrism is under very active development, so expect the configuration to change.

Parameter	Description	Default
image.repository	Image repository	photoprism/photoprism
image.tag	Image tag	20190703
image.pullPolicy	Image pull policy	IfNotPresent
debug	Enable verbose logging	true
persistence.enabled	Enable persistent storage	true
persistence.cachePath	Path to image cache	/assets/cache
persistence.importPath	Path to imported images	/assets/photos/import
persistence.exportPath	Path to exported images	/assets/photos/exports
persistence.originalsPath	Path to pre-existing photos	/assets/photos/originals
persistence.volumeMounts	VolumeMounts for Photoprism	See values.yaml
persistence.volumes	Volumes for Photoprism	nil
persistence.volumeClaimTemplates	VolumeClaimTemplate for Photoprism	See values.yaml
service.type	Photoprism service type	ClusterIP
service.port	HTTP to expose service	80
ingress.enabled	Enable ingress rules	false
ingress.annotations	Annotations for ingress	{}
ingress.hosts	Hosts and paths to respond	See values.yaml
ingress.tls	Ingress TLS configuration	[]
resources.requests.memory	Indexing photos requires a bit of memory	2Gi
database.driver	mysql or internal are supported	internal
database.name	Remote database name	nil
database.user	Remote database user	nil
database.password	Remote database password	nil
database.host	Remote database host	nil
database.port	Remote database port	nil

For setting nested values, it's generally easiest to just specify a YAML file that with the correct values:

$ helm install p80n/photoprism-helm --name my-release -f values.yaml

You can specify each parameter using the --set key=value[,key=value] argument to helm install, but for nested values, it's complicated. For example:

$ helm install p80n/photoprism-helm --name my-release \
    --set=image.tag=latest \
    --set=volumes[0].name=originals --set=volumes[0].nfs.server=my.nfs.server --set=volumes[0].nfs.path=/path

Persistence

It's important to configure persistent storage (e.g., NFS) for any sort of real-world usage. I've been running PhotoPrism using two NFS shares: one for PhotoPrism's thumbnails cache, and one pointing to where I store my original images in Lightroom (read-only). This has been working well for me; keeping PhotoPrism assets separate keeps my Lightroom workspace ~~uncluttered~~ less cluttered.

If you don't enable persistence, you can still take PhotoPrism for a spin; you'll just have to start from scratch if the pod dies or gets scheduled on a different node.

Database

PhotoPrism can be run without any external dependencies. If no remote database is provided, PhotoPrism will run TiDB internally. However, you'll still want to make sure that the database files are stored on persistent storage. See values.yaml for the path to TiDB's files.

Alternately, if you prefer to run the database separately, you can point PhotoPrism at your remote instance. MySQL and TiDB are both supported and are fairly equivalent on performance. In my experience, indexing photos is faster with MySQL, possibly due to faster write performance.

Note: Even if your remote database is TiDB, you still specify mysql for the driver.

Accessing PhotoPrism

The default values will only expose PhotoPrism inside your cluster on port 80. Some options for accessing PhotoPrism from outside your cluster:

Configure ingress rules for use with a reverse proxy
Change the service type to NodePort and pick a free port to expose
Access it from your client with kubectl port-forward

Need Help?

If you have questions about this Helm chart, or have trouble getting it deployed to your cluster, feel free to open an issue.

If you have issues with PhotoPrism itself, you may want to head over to their issues page.

casidiablo / photoprism-helm