PhotoStructure for Servers

PhotoStructure can run on both Desktops and on “headless” servers (like x64-based NAS).

How are the desktop & server editions of PhotoStructure 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 either a server or another computer, install PhotoStructure on that computer, and the library will open seamlessly (even if it’s a different operating system).

The desktop edition has a splash screen, 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.

The web, sync, and sync-file services are identical across editions.

Note that PhotoStructure for Servers requires command-line and networking expertise. If you want an easy point-and-click installation, you should try out PhotoStructure for Desktops.

Two ways to run PhotoStructure for Servers #

There are two ways to run PhotoStructure on headless systems: either with PhotoStructure for Docker, or without containerization, using PhotoStructure for Node. There are pros and cons to both approaches.

PhotoStructure for Docker #

Pros: #

  • PhotoStructure can run on any docker server that hosts x64 Linux 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 use watchtower, upgrades are completely automatic.

Cons: #

  • “Scan all volumes” doesn’t work: you’ll need to explicitly export volumes 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.
  • PhotoStructure won’t have access to physical volume metadata, which can cause issues with volume UUIDs. Read this to understand and handle this issue.

Continue with PhotoStructure for Docker, or docker-compose

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 semi-automatic.
  • If you really want to run PhotoStructure on a Raspberry Pi, (caution: it’s slow!), this is the only option available to you, as the docker images are not multiarch (yet).

Cons: #

  • You’ll need to install several other packages (but it’s just apt get or brew install)

Continue with PhotoStructure for Node.

Configuration #

See advanced-settings for information about PhotoStructures settings files.

Logging #

  • By default, see ~/.config/PhotoStructure/logs
  • The log directory, verbosity, and formatting are all configurable via ~/.config/PhotoStructure/settings.toml. Search for LOG.
  • You can run photostructure logtail to view log messages as they are emitted from all current running processes.
  • You can run photostructure logcat <path-to-logfile.log>... to pretty-print .log and .log.gz JSON files.

Library files #

$PS_LIBRARY_PATH/.photostructure contains your library database, as well as image and video previews of all the assets in your library. Opening your model DB in another application (like DB Browser for SQLite) should only be done when PhotoStructure is not running.

Service architecture #

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

PhotoStructure processes

PhotoStructure processes

main #

This process manages web and sync processes, restarting them if they crash or are unresponsive, and restarting sync if the library settings change.

web #

This process hosts the web-based user interface.

sync #

This process scans directories for potential library assets and asks a cluster of sync-file processes to import those files.

sync-file #

Expect several of these processes (correlated to the number of CPU cores your system has). These processes do all the work necessary to import files into your library, including building preview images and asking FFmpeg or VLC to transcode videos.

ExifTool, jpegtran, dcraw, FFmpeg, VLC, SQLite, PowerShell, wmic, df, gio, diskutil #

These tools will be spawned as needed for

  • Extracting photo and video metadata (ExifTool)
  • Losslessly rotating images (jpegtran)
  • Extracting RAW images (dcraw)
  • Transcoding videos to be viewable on a browser (FFmpeg or VLC)
  • Compressing and validating library databases (SQLite)
  • Extracting volume metadata (PowerShell, wmic, df)
  • Notifying PhotoStructure when volumes are mounted or unmounted (gio, diskutil)
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!