PhotoStructure for Servers

PhotoStructure editions đź”—

PhotoStructure supports many different computer setups with the following editions:

How are these editions different? đź”—

All editions of PhotoStructure, running on any operating system, are designed to be interoperable with each other, and the main user interface is the same.

In other words, you can “test the waters” by using PhotoStructure for Desktops, import the files on one computer, and then move your library to another computer, use any edition of PhotoStructure, and the library will open seamlessly, even if it’s a different operating system.

The desktop edition has a menu bar, a system tray, and supports automatic upgrades.

The server editions provide access to command-line tools that are useful for managing libraries and manually importing files and directories.

Note that PhotoStructure for Docker and Node both require some amount of expertise with the command line and network routing. If you want an easy point-and-click installation, you should try out PhotoStructure for Desktops.

PhotoStructure for Docker đź”—

Pros đź”—

  • PhotoStructure can run on any docker server that can host linux/x64 or linux/arm64 images.
  • You don’t need to install anything other than Docker on your computer.
  • Running PhotoStructure within a Docker container provides a layer of security for your host system (especially if you run PhotoStructure as a non-root user).
  • If you opt to use watchtower, upgrades are completely automatic.

Cons đź”—

  • You’ll need to explicitly bind-mount the directories you want to import into your PhotoStructure docker container.
  • You’ll need to install Docker on your host machine. This may require enabling VT-x or AMD-V in your BIOS.
  • Old AMD-64 CPUs, like AMD Phenom II, may not be able to run the docker image, as the binaries use some recent CPU extensions (like SSE3 and SIMD). If you have one of these older CPUs, use PhotoStructure for Node.
  • macOS users on Apple Silicon will be running through the Rosetta emulator
  • PhotoStructure won’t have access to physical volume metadata, which can cause issues with volume UUIDs. Read this to understand and handle this issue.

Instructions đź”—

See the installation instructions for:

PhotoStructure for Node đź”—

Pros đź”—

  • “Scan all volumes” works automatically. You don’t have to export drives manually from your host machine into your container, like you do with Docker.
  • Volume UUIDs are supported.
  • Upgrades are checked for and applied on restart automatically.
  • macOS users on Apple Silicon run “native” (rather than through the Rosetta emulator like on docker)

Cons đź”—

  • You’ll need to install several software packages that are required by PhotoStructure

Instructions đź”—

See the installation instructions for PhotoStructure for Node

Support for pidfiles đź”—

Depending on your system setup, you may want to use a process id file, or “pidfile,” to control one or more instances of PhotoStructure.

First, set up a PS_PIDFILE environment variable to the absolute path of a file that PhotoStructure will be able to write to. /var/run/user/$PUID/photostructure.pid (if you’re going to have multiple concurrent libraries running with different user ids) or /var/run/photostructure.pid (if you’re only running one instance on a host or container) are reasonable defaults. If the parent directory of the path doesn’t exist, PhotoStructure will try to mkdirp the parent directory, but it needs to be writable as the PUID/PGID user and group. The path could be something like /var/run/user/$PUID/photostructure.pid.

The next time you launch the main process, you should see this file be created, and the contents will contain the process id of the main process.

To shut down that instance of photostructure, you can either send that pid a SIGINT or SIGTERM, or use photostructure --stop --pidfile=/path/to/pidfile to kill the running instance. Running with --stop will exit with 0 only after the main library has shut down gracefully, or exit with non-zero if there’s anything amiss. Make sure the pidfile paths match.

Service architecture đź”—

This section is only provided to explain what processes you should expect on your system.

PhotoStructure processes

PhotoStructure processes

  • main manages web and sync processes, restarting them if they crash or are unresponsive, and restarting sync if the library settings change

  • web hosts the web-based user interface

  • sync scans directories for potential library assets and imports those files

  • worker processes are used by web and sync to improve concurrency

  • exiftool reads and writes photo and video metadata

  • dcraw extracts RAW images

  • ffmpeg extracts video thumbnails and transcodes videos to be viewable on a browser

  • sqlite validates and recovers library databases

  • PowerShell and df are used to gather volume metadata

  • gio and diskutil notifies when volumes are mounted or unmounted

See also đź”—

Photo of Matthew

Hi! I’m Matthew, the author of PhotoStructure. I’m a dad, amateur photographer, and author of open source, adtech, fintech, and edtech software since the turn of the millennium. He/him. I am building a self-hosted, safe, and fast new home for all your photos and videos.
Your memories deserve PhotoStructure. Try it out for free!