What is OpenImmo and why does it matter?

OpenImmo is a file format. Almost every German estate agency program can export its properties in it. That is exactly why I start there. I do not have to build a separate connection for every program. It is enough to understand the one format they all speak.

Why is every job processed on its own?

For protection. The files come from other people's programs and often contain something unexpected. If every job runs in its own sealed-off area, a fault can take down neither other customers nor the service itself. After the job the area is deleted, and the memory is free again.

Why do the files arrive by FTP?

Because the agents' software can do it. FTP is an old, simple way to transfer files. A more modern way is useless if the customer would have to switch software for it. The connection has to start where the data already comes out today.

What does this kind of automation save?

The double upkeep and the mistakes that come with it. How many hours that is depends on the number of properties. I do not have reliable figures for it yet. So none is stated here.

LiveSL-04

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 files those programs produce anyway and keeps the website up to date by itself. Every job is processed separately from all others. That way a fault in one agency's data cannot affect another.

Visit the project

SL-04Live

ImmoSync

3 · Customers in operation

207 · Processing runs

Verified numbers

Customers in operation: 3Source: Production server, as of 7 Sep 2026
Processing runs: 207Source: Job queue on the production server, as of 7 Sep 2026
Running continuously since: 27 Apr 2026Source: Server log, first entry 27 Apr 2026, latest 4 Sep 2026
Ways to run the service: 3Source: docker-compose.yml, .production.yml and .vps.yml, as of 11 Aug 2026
New version goes online by itself: After every changeSource: .github/workflows/deploy.yml

Starting point

Software for estate agents can export its properties as a file. The format for that has been common in the industry for years. But websites cannot do anything with these files. So every property is maintained twice: once in the specialist software and once by hand on the website. That costs time every week. And sooner or later the two no longer match.

Outcome

A running service at its own address. It accepts the files from the agents' software and keeps the website up to date. Every job is processed on its own and leaves nothing behind. That way one customer's faulty data cannot affect another.

The problem is double upkeep, not missing technology

Estate agency software can export its properties. Websites can read data in. Still, many agencies maintain every property twice. Because nobody translates between the file from the software and what a website understands.

The result is familiar from many small businesses. A task comes up every week. Nobody likes doing it, and nobody really owns it. Mistakes only surface when a customer asks about a flat that was sold long ago.

The starting point was the format, not the program

There are many estate agency programs. Building a separate connection for each would be endless work. But they all export their data in the same format.

So the processing starts at the format, not at the program. That is what separates a product from a row of one-off connections. When a new customer arrives with different software, I usually do not have to build anything new.

For the same reason the files arrive by FTP. It is not modern. But the agents’ software can do it. A route that would make the customer switch software does not get used.

Why every job runs on its own

The service processes other people’s files from other people’s programs. Such files often look different from how they should. Sometimes details are missing, sometimes images point nowhere, sometimes a file is huge.

That is why every job gets its own sealed-off area. It is processed there, and afterwards the area is deleted. If a job fails, it takes down neither other customers nor the service. And the memory it used is free again.

For the technically minded: the technology behind it

For each job the manager starts a short-lived Docker container and discards it afterwards. Intake via FTP ingest, OpenImmo XML processing in Node.js, interface in Vue behind Nginx. Three Compose variants, deployment through GitHub Actions on every merge.

That decision makes the project more than a small helper script.

What is honestly missing here

Hours of work saved. That would be the most convincing number in this report, and I cannot back it up at the moment. What I can back up is above: three customers, 207 runs and uninterrupted operation since April 2026.

I do not write down a number I cannot back up. Not even when it would read well.

Frequently asked

What is OpenImmo and why does it matter?: OpenImmo is a file format. Almost every German estate agency program can export its properties in it. That is exactly why I start there. I do not have to build a separate connection for every program. It is enough to understand the one format they all speak.
Why is every job processed on its own?: For protection. The files come from other people's programs and often contain something unexpected. If every job runs in its own sealed-off area, a fault can take down neither other customers nor the service itself. After the job the area is deleted, and the memory is free again.
Why do the files arrive by FTP?: Because the agents' software can do it. FTP is an old, simple way to transfer files. A more modern way is useless if the customer would have to switch software for it. The connection has to start where the data already comes out today.
What does this kind of automation save?: The double upkeep and the mistakes that come with it. How many hours that is depends on the number of properties. I do not have reliable figures for it yet. So none is stated here.

All work