Fredy: a self-hosted crawler that watches 20 European property portals and pings you once per listing

The problem Fredy targets: five portals, one flat, five notifications

Anyone searching for a flat in a German-speaking city learns the same lesson quickly. The good listings appear on ImmoScout24, Immowelt and Kleinanzeigen within hours of each other, sometimes posted by the same agency with a different headline. Manual refreshing does not scale, and portal email alerts arrive late and cannot be filtered by travel time. Fredy's stated goal is to keep searching on your behalf and deliver results to Slack, Telegram, Email, Discord or ntfy, so you stop opening tabs. The audience is narrow and specific: self-hosters in Germany, Austria, Switzerland, Spain, Italy and Portugal, which is the market coverage the README names. If your search is in a country outside that list, the provider set is the first thing to check. The project is written in JavaScript, licensed Apache-2.0, and the README describes a Web UI for creating and managing searches rather than a config file you hand-edit, which changes the operational shape compared with most scrapers in this category.

How the pipeline works: crawlers, a dedup step, then notification channels

The README describes the flow in one sentence: Fredy scrapes the portals, drops duplicates across platforms, and notifies you as soon as a new listing appears. The deduplication rule is the part worth reading twice. According to the README, matching happens on living space, rooms and location rather than on the headline, because no two portals write a listing title the same way. That is a deliberate choice with a known failure mode: two genuinely different flats in the same building with identical square metres and room count can collapse into one notification, and you would only see the second one if you checked the portal yourself. The README also states that Fredy uses a reverse-engineered ImmoScout Mobile API, which is a different retrieval path from HTML scraping and explains why ImmoScout has its own section in the documentation. Searches run on configurable intervals and can be restricted to working hours, so the crawler is not hammering portals around the clock. The repository layout, judging by the topics list, includes Puppeteer, which points to headless browser rendering for at least some providers.

Getting an instance up: one docker run and a Web UI

The README gives a single command for the Docker path. `docker run -d --name fredy -v fredy_conf:/conf -v fredy_db:/db -p 9998:9998 ghcr.io/orangecoding/fredy:master` starts the container, and the Web UI is served on port 9998. Two volumes matter: `/conf` holds `config.json`, and `/db` holds the database. The README is explicit that no configuration file is needed to start, because Fredy creates `/conf/config.json` on first run if it is missing, and that file only holds the database path. Everything else, including searches and notification targets, is configured in the Web UI and stored in the database. That is a meaningful operational difference from file-driven scrapers: backing up your search definitions means backing up the database volume, not copying a YAML file. Images are built for `linux/amd64` and `linux/arm64`, so a Raspberry Pi or an ARM VPS is viable. There is also a pre-release channel, `ghcr.io/orangecoding/fredy-pre-release:latest`, which follows the `develop` branch. The README says it goes through the same pipeline (lint, format check, offline test suite) but has not been through master, and recommends it for trying features or verifying a fix, not for an instance you rely on.

Travel time and the financing calculator are the filters that justify the setup

Two features go beyond alerting. The first is travel time. The README is careful to distinguish it from straight-line distance: Fredy computes the real journey from your own address by public transport, car, bike or on foot, and the map draws the transport network, marks every stop and shows next departures. There is a filter to match on that travel time, which is the practical part. Anyone who has filtered listings by radius knows the problem: a flat 4 km away across a river can be a 50 minute commute, and a flat 9 km away on a direct train line can be 20 minutes. The second is the financing calculator. You enter income, living costs and savings once, and every listing is measured against them as comfortably affordable, a stretch, or out of reach, separately for renting and for buying. Both features depend on external services (routing and geocoding, transit data) that the README does not enumerate, so the honest position is that their reliability on your network is unverified from the material available. They are also the features most likely to be the reason to pick Fredy over a plain RSS-to-Telegram bridge.

Where Fredy breaks: reverse-engineered APIs, bot detection and duplicate collapse

The README devotes a section to bot detection and proxies, and another to Immoscout specifically, which tells you where the fragility lives. A reverse-engineered mobile API is not a contract. When ImmoScout changes its mobile client, the endpoint Fredy calls can change with it, and the fix lands in a release rather than in your configuration. The same applies to the twenty portals: HTML markup changes break Puppeteer selectors, and the README's provider list is the boundary of what will ever work. Bot detection is a second axis. The existence of a proxy section implies that some portals rate-limit or fingerprint requests, and a self-hosted instance on a residential IP may behave differently from one on a datacentre IP. The third failure mode is the deduplication rule itself, described above: matching on living space, rooms and location rather than the headline is a trade-off, and it trades recall for quiet. If you would rather see the same flat twice than miss one, the feature works against you. Finally, the 20-portal coverage is concentrated in six countries. Outside those, Fredy has nothing to scrape.

How Fredy differs from a generic scraper or a portal's own alerts

The obvious alternative is the alert feature built into each portal. ImmoScout24, Immowelt and Kleinanzeigen all send email notifications for saved searches. The difference is architectural: a portal alert only knows its own inventory, so a flat cross-posted on three sites produces three emails, and none of them can be filtered by how long the commute actually takes. Fredy sits above the portals and normalises across them, which is the whole point of the dedup step and the travel-time filter. The second alternative is a general-purpose scraper framework such as a Puppeteer script you write yourself, or a hosted change-detection service. A hand-written script gives you exact control over selectors and no dependency on someone else's release cadence, but you own every breakage, and you would have to build the cross-portal matching, the notification fan-out to Slack, Telegram, Email, ntfy, Discord, Mattermost, Pushover and Apprise, and the Web UI yourself. Fredy's value is that those parts already exist and are maintained by someone else. The cost is that you inherit their breakage schedule too, and the release history shows the cadence: 27.5.0, 27.5.1 and 27.5.2 all landed within three days of each other in September 2026, which is either rapid response to portal changes or a sign of churn. The material does not say which.

Licence, upgrade cost and what to verify before you commit

Fredy is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files, and it includes a patent grant. That is a permissive licence; it does not obligate you to publish your changes. The practical licence question is not Fredy's code but the portals' terms of service, which the material does not address, and scraping may conflict with them regardless of what the software licence allows. On upgrade cost: the README's pinning advice is the concrete detail. `:master` follows the master branch, so a `docker pull` can move you onto an unreviewed state, and the README suggests pinning a version tag such as `ghcr.io/orangecoding/fredy:26.5.1` instead. Given the release density, pinning and upgrading deliberately is the lower-risk path. Two things to verify on your own instance, because the material cannot confirm them: whether your target portal appears in the full provider list, and whether the travel-time and financing features can reach their routing and transit data sources from wherever you host. If either fails, you are left with a deduplicating notifier, which is still useful but a smaller thing than the README promises.

Editorial conclusion

Fredy fits a self-hoster hunting in Germany, Austria, Switzerland, Spain, Italy or Portugal who already runs Docker and wants one alert per flat instead of five. It is the wrong tool if you need a guaranteed, contractual feed, if you are outside those markets, or if you cannot tolerate a scraper breaking when a portal changes its markup. Before committing, verify three things: that your target portal is in the provider list, that the travel-time and financing features can reach the routing and geocoding services they depend on from your network, and that you are willing to run the pre-release image only to test fixes rather than to host on. The pinning behaviour is the deciding detail: `:master` follows the branch, so a version tag is the only way to hold a known state.

Official sources

1. License: Apache-2.0
2. orangecoding/fredy on GitHub
3. Project website
4. README
5. Releases