This week in past

A quiet, single-purpose tool that does one thing and doesn’t apologize for it.

TL;DR

• What it is: A self-hosted slideshow server that reads your local photo library and displays images taken during the current calendar week in previous years — the “memories” feature from Google Photos, running on your own hardware [README].
• Who it’s for: Anyone who left Google Photos (or iCloud) for a self-hosted photo manager like Immich or PhotoPrism and misses the nostalgia slideshow on their TV or NAS dashboard.
• Cost savings: Google Photos charges $2.99–$9.99/mo for storage tiers after the 15GB free limit. This Week in Past runs as a statically compiled binary with no dependencies — it costs nothing to run on hardware you already own [README].
• Key strength: Genuinely single-purpose and honest about it. Points it at a folder, ships a slideshow. No database to manage, no user accounts, no bloat.
• Key weakness: It’s a viewer, not a manager. No uploads, no editing, no album organization — you need a separate photo manager for that. With only 100 GitHub stars, this is a niche tool with minimal community support and no third-party reviews to draw from.

---

What is This Week in Past

This Week in Past was built by a developer who migrated their photo collection from Google Photos to PhotoPrism and immediately noticed what was missing: the automated “on this day” slideshow that Google generates for you [README]. Rather than going back, they built it themselves.

The concept is narrow by design. At startup, the application reads the EXIF metadata of every image in the folder you point it at, caches that metadata in memory, and serves a web-based slideshow. When you open it, it shows photos taken during the current calendar week from all previous years. If no photos match the current week, it falls back to a random selection so the screen never goes blank [README].

That’s essentially the entire product. There’s no AI tagging, no facial recognition, no sharing feature, no mobile app with push notifications. The GitHub description puts it plainly: “Aggregate images taken this week, from previous years and presents them on a web page with a slideshow.”

The binary is written in Rust and compiled completely statically — no dependencies on system libraries like glibc — which means it runs on whatever you have: an x86 server, an ARM NAS, a Raspberry Pi [README]. Docker and Docker Compose are the primary deployment paths, but native binaries for amd64, arm64/v8, arm/v7, and arm/v6 are published on the releases page [README].

The project is MIT licensed, listed in the Awesome-Selfhosted directory under Photo Galleries, and has accumulated approximately 100 GitHub stars — a small but stable signal that people deploy and keep running it [README].

---

Why People Choose It

The motivation in the README is honest and relatable: “When I migrated my photo collection from Google Photos to a locally hosted instance of PhotoPrism, I missed the automatically generated slideshow feature of Google Photos, here it is now.” [README]

That captures the exact use case. Google Photos’ “memories” and “on this day” features are genuinely well-executed — they surface photos at the right moment without requiring you to do anything. When people move to self-hosted photo managers, they typically gain privacy and data control but lose the ambient, automatic nostalgia layer. This Week in Past fills that gap.

There’s no substantial third-party review coverage to synthesize here — the tool is small enough that it hasn’t appeared in self-hosting publications beyond directory listings [1][2][3]. The Docker Hub pull count (visible in the README badge) is the closest proxy for real-world adoption, and the multi-architecture support suggests it’s deployed on the full range of hardware people actually run in home labs.

The appeal is simple: it has no opinions about how you organize photos. It mounts your folder read-only, reads EXIF dates, and does its job. If you already have a working photo manager — Immich, PhotoPrism, a network share — you don’t need to change anything. You add This Week in Past on top.

---

Features

Based on the README and configuration reference:

Core slideshow engine:

• Reads EXIF metadata from images at startup, caches in memory (no repeated disk scanning after init) [README]
• Filters by current calendar week across all previous years [README]
• Fallback to random images when no week-matching photos exist [README]
• Configurable slideshow interval via SLIDESHOW_INTERVAL environment variable [README]
• Mounts images read-only — it cannot modify your photo library [README]

Optional weather widget:

• Displays current weather on the slideshow if enabled [README]
• Requires an OpenWeatherMap API key (OPEN_WEATHER_MAP_API_KEY) and WEATHER_ENABLED=true [README]
• Location resolved via BigDataCloud API (BIGDATA_CLOUD_API_KEY) [README]

Multi-source image support:

• RESOURCE_PATHS accepts a comma-separated list of folders — you can point it at multiple directories [README]
• Works with any standard image format that carries EXIF date metadata

Deployment options:

• Docker with a single docker run command [README]
• Docker Compose for persistent configuration [README]
• Native binary (statically compiled, no runtime dependencies) for Linux on amd64/arm64/arm [README]

REST API:

• Listed as a canonical feature in the profile metadata, though the README excerpt doesn’t detail endpoints. Likely covers triggering refreshes or fetching the current image list programmatically.

Multi-architecture support:

• Official Docker images for amd64, arm64/v8, arm/v7, arm/v6 — runs on Raspberry Pi, QNAP NAS, Synology [README]

What it does not do: photo uploading, album management, user authentication, mobile app, facial recognition, sharing links, or AI features. This is a one-way display tool.

---

Pricing: SaaS vs Self-Hosted Math

Google Photos (the incumbent comparison):

• Free tier: 15GB shared across Google account
• 100GB: $2.99/mo ($35.88/yr)
• 200GB: $4.99/mo ($59.88/yr)
• 2TB: $9.99/mo ($119.88/yr)

Google Photos is cloud storage + manager + memories — This Week in Past is only the memories/slideshow layer. The comparison only applies if you’ve already self-hosted your photo storage and are looking to replace that specific feature.

This Week in Past self-hosted:

• Software license: $0 (MIT) [README]
• Runs on hardware you already own: additional cost is negligible
• On a dedicated $6 Hetzner VPS: $72/yr for the whole machine, shared with other services

If you’re paying Google $2.99–$9.99/mo primarily for the memories feature (and you’ve already moved your actual storage elsewhere), this replaces that trigger for free. If you’re paying Google for storage and memories together, you’d need to combine this with a photo manager like Immich to achieve feature parity — and at that point the math is a bigger migration decision, not just about this tool.

The OpenWeatherMap API key (optional) is free at hobby usage levels. BigDataCloud has a free tier for geocoding. Neither is a meaningful cost.

---

Deployment Reality Check

Setup is straightforward for anyone comfortable with Docker. The basic Docker Compose configuration is three lines plus environment variables [README]:

services:
  this-week-in-past:
    image: rouhim/this-week-in-past
    volumes:
      - /path/to/pictures:/resources:ro
    ports:
      - "8080:8080"
    environment:
      SLIDESHOW_INTERVAL: 10

Mount your photo directory read-only, expose port 8080, done. The application reads metadata at startup — for a large library (50,000+ photos), expect a startup delay while it scans and caches. After that, it’s just serving a web page.

What can complicate setup:

• EXIF metadata must be present in image files for date-based filtering to work. Photos without EXIF dates (screenshots, downloads, some scanned images) won’t be correctly placed in the calendar week filter.
• Weather widget requires separate API keys from two services. Not difficult, but an extra step if you want it.
• There’s no built-in authentication. The slideshow is served as an open web page — appropriate for a local network display (TV, kiosk), not for exposing to the internet without a reverse proxy with auth in front of it.
• The REST API surface isn’t documented in the README excerpt, so programmatic integration requires reading the source code.

For a technical user: setup is under 15 minutes. For someone new to Docker: 1–2 hours following a general Docker Compose guide. An online demo is available at http://152.70.175.46/ if you want to see the UI before deploying [README].

---

Pros and Cons

Pros

• Zero-dependency binary. Rust compiled to a fully static musl binary. No glibc version conflicts, no runtime surprises. Runs on anything Linux [README].
• Read-only by design. The photo volume is mounted :ro. The application literally cannot modify your photo library — a genuine safety guarantee [README].
• MIT licensed. Do whatever you want with it [README].
• Multi-arch Docker images. arm64 and arm/v7 support means it deploys on Raspberry Pi and ARM-based NAS devices without cross-compilation headaches [README].
• No external database. Metadata is cached in memory, app data in a local folder. No PostgreSQL, no Redis, no external dependencies.
• Listed on Awesome-Selfhosted. A basic quality signal that someone reviewed it for inclusion [README].
• Sensible fallback behavior. Random images when no week-match exists means the display is never empty [README].

Cons

• 100 GitHub stars. This is a small project. If it stops being maintained, there’s no large community to pick it up. Issues may go unanswered [README].
• No authentication. Fine for a TV on your home network; a security gap if you try to expose it externally without a reverse proxy.
• EXIF-dependent. Photos without proper EXIF date metadata won’t participate in week filtering. This is a real issue for libraries with mixed sources (old scans, messenger downloads, screenshots).
• Display only. You need a separate photo manager. This doesn’t replace Immich or PhotoPrism — it sits alongside them.
• No third-party reviews. There’s no independent coverage to validate real-world performance at scale, stability over time, or edge case behavior.
• REST API underdocumented in publicly available materials. The feature exists but the surface isn’t clear without reading source code.
• Weather widget requires external API keys. Minor friction, and weather APIs have their own rate limits and potential future costs.

---

Who Should Use This / Who Shouldn’t

Use This Week in Past if:

• You’ve already moved to a self-hosted photo manager (Immich, PhotoPrism, a network share) and miss the automatic “memories” slideshow from Google Photos.
• You want something running on a TV, a wall display, or a home dashboard that cycles through historical photos without requiring any interaction.
• You’re on a Raspberry Pi or ARM NAS and want a genuinely lightweight option — a statically compiled Rust binary is about as lightweight as it gets.
• Your photo library is well-organized with proper EXIF metadata (typically true if you’ve used a camera or an unmodified smartphone library).

Skip it if:

• You’re looking for a complete self-hosted photo solution. This is not Immich. It doesn’t store, manage, or organize photos.
• Your library includes a large number of photos without EXIF metadata — the core feature won’t work for them.
• You need access control — no built-in authentication means you’ll need a reverse proxy with auth before any internet-facing deployment.
• You need active community support or long-term maintenance guarantees. At 100 stars, this is a single-developer project.

---

Alternatives Worth Considering

• Immich — Full-featured self-hosted Google Photos replacement. Has its own “memories” / “on this day” feature built in. If you don’t have a photo manager yet, start here rather than building a stack around This Week in Past. Active development, large community, 60,000+ GitHub stars.
• PhotoPrism — The self-hosted manager specifically mentioned in This Week in Past’s origin story [README]. More search/discovery focused than Immich, also has timeline browsing. No built-in “this week in past” equivalent, which is why this tool exists.
• Lychee — Photo management with public album sharing. No memories feature.
• LibrePhotos — Open-source Google Photos alternative with face recognition. Less actively maintained than Immich.
• Google Photos — The tool this replaces. If you have fewer than 15GB and don’t care about privacy or vendor lock-in, the free tier is still the easiest option.
• Piwigo — Older, established photo gallery. Plugin ecosystem but no automatic memories feature out of the box.

The realistic decision tree: if you haven’t migrated away from Google Photos yet, start with Immich — it replicates the full Google Photos experience including memories, and you don’t need This Week in Past at all. If you’re already on Immich, check whether its built-in memories feature meets your needs before adding another container. This Week in Past is most useful when you’re running a simpler photo storage setup (a mounted share or PhotoPrism without memories support) and want just this one feature.

---

Bottom Line

This Week in Past does one thing: surfaces photos from this calendar week in previous years, running entirely on your hardware, with zero dependencies and a read-only mount to your photo library. That’s it. The scope is honest, the execution is solid, and the Rust binary compiles away any concerns about runtime environment. For someone who left Google Photos for a self-hosted photo manager and finds themselves missing the ambient nostalgia of the memories feature, this is exactly the correct tool. For anyone expecting a full photo management platform, it’s the wrong tool entirely. At 100 GitHub stars with minimal third-party coverage, it’s genuinely a small project — but “small” and “unmaintained” aren’t the same thing, and the multi-arch Docker images suggest it’s actively kept current. If the use case matches, the setup is under 15 minutes and the ongoing operational overhead is essentially zero.

---

Sources

1. Ethan Sholly, selfh.st — “This Week in Self-Hosted (18 October 2024)”. https://selfh.st/weekly/2024-10-18/
2. Ethan Sholly, selfh.st — “Self-Host Weekly (23 May 2025)”. https://selfh.st/weekly/2025-05-23/
3. Ethan Sholly, selfh.st — “This Week in Self-Hosted (28 February 2025)”. https://selfh.st/weekly/2025-02-28/

Primary sources:

• GitHub repository and README: https://github.com/rouhim/this-week-in-past (~100 stars, MIT license)
• Docker Hub: https://hub.docker.com/r/rouhim/this-week-in-past
• Live demo: http://152.70.175.46/