PriceBuddy: a self-hosted price tracker for stores nobody has written an integration for

The problem PriceBuddy picks: stores with no integration to plug into

Most price trackers only work where someone has already built a connector. That is fine for Amazon and a handful of large retailers, and useless for a regional shop, a marketplace listing, or a hobby supplier that never appears in anyone's supported-store list. PriceBuddy's README states the project was inspired by Discount Bandit, and names the difference directly: it aims to track products from arbitrary stores without requiring a code change for each retailer. That is the whole pitch. You paste a product URL, the app attempts to read the title, image, price and availability, and where a site is awkward you tune the scrape strategy rather than waiting for a maintainer to ship support. The intended user is someone running their own server who tracks household items, computer parts, hobby gear, subscriptions or marketplace listings, and who wants the price history to stay on their own disk. Multi-user accounts, tags and filters suggest shared use, so a household or a small team can each keep separate targets and notification preferences.

How scraping, scheduling and notifications fit together

PriceBuddy is a Laravel application with a Filament admin interface, packaged so that the scheduler runs inside the same Docker image. The README is explicit that you do not need a separate cron container: the image includes the scheduler that checks prices, updates history and sends notifications. That single-container decision removes a common source of self-hosted breakage, where the web process runs and the queue worker silently dies. The data flow implied by the documentation is: a product URL is added, a scrape strategy is attached to that store, the scheduler fetches the page on a schedule, and the parsed price and availability are written to history. Availability is modelled as distinct states (in stock, pre-order, back order, special order, out of stock, discontinued), which matters because a low price on a discontinued listing is noise. Alerts fire on a target price or a percentage drop, and can be delivered through the app, email, Pushover, Gotify, Apprise, Telegram, Discord or ntfy. Unit price calculation is included so a 10-pack and a 3-pack can be compared on the same basis. AI providers (OpenAI, Anthropic, Gemini or a local Ollama instance) are optional and off by default, used to recover missing data or help repair scraping rules. Treating AI as a fallback rather than the primary parser is the right call: it keeps the default path deterministic and cheap.

Getting it running with Docker, and the two settings worth changing first

The README gives a short install path. Download docker-compose.yml, adjust it for your environment, then run:

touch .env docker compose up -d

With the defaults the app is reachable at http://localhost:8080, and the documented default login is admin@example.com with the password admin. The README says to change that password immediately, and given the app exposes your watchlist and notification credentials, that is not optional advice. Most settings live in the app itself; advanced options go in .env. One .env key is documented in the README: AFFILIATE_ENABLED=false, which turns off the affiliate codes the project adds for a small number of stores listed in config/affiliates.php. If you would rather not have outbound links rewritten, set that before you start adding products, not after. For development the README points at Lando, with lando start as the entry command, and notes that coding standards, static analysis and tests use Pint, PHPStan and Pest/PHPUnit. If you want to run it outside Docker, the README says docker/php.dockerfile and docker-compose.yml are the best references for the required services and PHP extensions, which is a polite way of saying you are on your own for the runtime.

Where PriceBuddy breaks, and who should not use it

The honest limitation is in the README's own phrasing: many stores work straight away, and trickier sites need a tuned scrape strategy. That means the project does not remove the maintenance burden of scraping, it moves it to you. A retailer that redesigns its product page can break a strategy, and the fix is manual. If you track twenty stores and three of them change markup in a month, you are the integrations team. The AI fallback can recover missing fields, but it is off by default and depends on an external provider or a local Ollama instance you have to run and pay for in compute. There is a second boundary worth stating: PriceBuddy is a watcher, not a buyer. Nothing in the material describes automatic purchasing or checkout, so if your goal is to snipe a limited drop the moment it goes live, this is the wrong tool. A third: the licence field for this repository is NOASSERTION, meaning no standard licence identifier is declared in the metadata. Before you build anything on top of it or redistribute a modified image, read the actual licence file in the repository rather than assuming a permissive default. I am not giving legal advice here; the point is that the metadata alone does not tell you.

Discount Bandit and Keepa: different answers to the same question

The README names Discount Bandit as the inspiration, so the comparison is fair. Discount Bandit is also self-hosted and PHP-based, and the stated difference is flexibility: PriceBuddy aims to handle arbitrary stores without a code change per retailer, where a per-retailer integration model requires someone to write and maintain each connector. If your shopping is concentrated in retailers that already have connectors in another tool, that tool's fixed connectors may be more reliable than a generic scraper, because a purpose-built connector knows the site's structure. The opposite case is the one PriceBuddy is built for: a long tail of stores nobody has integrated. Keepa occupies a third position entirely. It is a hosted service with deep historical data, and it is effectively limited to Amazon. If Amazon is your only concern, Keepa's history is broader than anything you will accumulate locally, and you will not maintain a server. PriceBuddy's counter-argument is control and scope: your history lives in your database, and the same watchlist can span Amazon, a marketplace listing and a small shop's own storefront. Choose based on whether your problem is depth on one retailer or coverage across many.

Maintenance cost: what you are signing up for after install

Release cadence is visible in the tags: v1.0.52 in early July 2026, v1.0.53 a few days later, and v1.0.54 in early August 2026. That is a project still moving, which cuts both ways. Fixes arrive, and so do changes you have to absorb. The upgrade path is a Docker image pull plus a compose restart, and because the scheduler lives in the same container, there is no second process to coordinate. What you cannot avoid is the ongoing scrape upkeep described above, plus the operational surface of whatever notification channels you enable. Each of Pushover, Gotify, Apprise, Telegram, Discord and ntfy means credentials stored in the app, and a silent failure in any one of them looks identical to a week with no price drops. The optional AI provider adds a second external dependency if you turn it on. None of this is unusual for self-hosted software, but it is the real cost of the flexibility the project advertises, and it is worth counting before you migrate a watchlist into it.

What to verify before you commit your watchlist

Start with the stores you actually care about, not the ones that demo well. Paste three or four real product URLs and check whether title, price and availability parse without tuning. If more than one needs manual work, that tells you how much of your time the tool will consume. Next, confirm the notification path end to end on your network: ntfy and Gotify are usually local, while Telegram and Discord leave your network, and a home server behind a restrictive firewall may not reach all of them. Then decide the affiliate question early by setting AFFILIATE_ENABLED=false in .env if you want it off, since config/affiliates.php only covers a small number of stores and the setting is easier to apply before products are added. Finally, check the licence file, because the repository metadata reports NOASSERTION and that is not enough to plan a redistribution around. If those four checks pass, the Docker install is two commands and the scheduler is already running.

Editorial conclusion

Adopt PriceBuddy if you already run Docker on a home server or VPS, you track products across several retailers, and you are willing to tune scrape rules when a store changes its markup. Do not adopt it if you expect every URL to work unattended, if you need a hosted service with no server to maintain, or if a single-retailer integration such as Keepa is enough for your use case. Before committing, verify three things: that your target stores parse correctly on first paste, that your chosen notification channel (email, Pushover, Gotify, Apprise, Telegram, Discord or ntfy) actually delivers from your network, and whether you are comfortable with the affiliate code behaviour in config/affiliates.php or want AFFILIATE_ENABLED=false set from the start.

Official sources

1. Issues
2. jez500/pricebuddy on GitHub
3. Project website
4. README
5. Releases