What is OpenImmo and why does it matter?

An XML format established for years, in which practically every German property software exports its listings. That is exactly why it is the right point of attack: instead of building an integration for each estate agency program, one processor for the format they all speak is enough.

Why a separate container per job?

Isolation. Property exports are foreign files from foreign systems, often with unexpected contents. A job running in its own short-lived container cannot take other customers or the service itself down when it fails — and the memory is reclaimed with the container anyway.

Why FTP for data ingest?

Because the estate agency programs can do it. A technically more modern interface is useless if it requires the customer to change their specialist software. The integration has to meet the data where it already comes out, not where the developer would prefer it.

What does this kind of automation actually save?

The duplicated maintenance work and the errors it produces. How much that is in hours depends on the size of the portfolio — I do not yet have defensible figures for this customer group, so none are stated here.

Live

When the same manual work comes back every week

Estate agencies maintain their properties in specialist software and then a second time on their own website. ImmoSync reads the standard export files those programs produce and keeps the website in sync automatically — each job in its own container that disappears afterwards.

Visit the project

Verified numbers

Commits: 382Source: git log, 24 Feb 2026 to 12 Jul 2026
Deployment variants: 3Source: docker-compose.yml, .production.yml and .vps.yml, as of 11 Aug 2026
Automated deployments: On every mergeSource: .github/workflows/deploy.yml

Starting point

Property software exports listings in an industry format that has been standard for years. Websites still cannot do anything with it, so listings get maintained twice: once in the specialist program, once by hand on the website. That costs time every week and reliably produces two datasets that drift apart.

Outcome

A running service on its own domain that accepts export files and keeps listing data in sync. The actual processing runs in short-lived containers started per job and discarded afterwards — so one customer's malformed data cannot affect another.

The problem is duplication, not missing technology

Property software can export. Websites can import. Agencies still maintain their listings twice — because nobody mediates between the export format and what a website understands.

The result is the classic state you find in many small businesses: a task that comes back every week, that nobody enjoys, that nobody owns, and where mistakes only surface when a customer asks about a property that sold long ago.

The point of attack was the format, not the software

There are many estate agency programs. Building an integration for each would be endless work. But they all export into the same industry format.

So the processing targets the format, not the program. That is the difference between a product and a series of one-off integrations: a new customer on different software normally needs no new development.

The same reasoning drives FTP ingest. Not because it is modern, but because the specialist programs can do it. An interface that requires the customer to change their software does not get used.

Why every job gets its own container

The service processes foreign files from foreign systems. Such files are regularly different from what the specification promises: unexpected character encodings, missing mandatory fields, images with broken references, occasionally absurd sizes.

Rather than catching all of that inside the main service, the manager starts a short-lived container per job and discards it afterwards. A job that fails takes neither other customers nor the service with it — and the memory it occupied goes away with the container.

That is the architectural decision that most distinguishes this project from a script.

What is honestly missing here

Customer numbers and hours saved. Both would be the most persuasive figures in this case study, and neither can I currently evidence. What is evidenced is above: the scope of the work, the deployment variants and the automated delivery.

A number I cannot evidence does not go on the page — not even when it would read well.

Frequently asked

What is OpenImmo and why does it matter?: An XML format established for years, in which practically every German property software exports its listings. That is exactly why it is the right point of attack: instead of building an integration for each estate agency program, one processor for the format they all speak is enough.
Why a separate container per job?: Isolation. Property exports are foreign files from foreign systems, often with unexpected contents. A job running in its own short-lived container cannot take other customers or the service itself down when it fails — and the memory is reclaimed with the container anyway.
Why FTP for data ingest?: Because the estate agency programs can do it. A technically more modern interface is useless if it requires the customer to change their specialist software. The integration has to meet the data where it already comes out, not where the developer would prefer it.
What does this kind of automation actually save?: The duplicated maintenance work and the errors it produces. How much that is in hours depends on the size of the portfolio — I do not yet have defensible figures for this customer group, so none are stated here.

← All work