Real Hotel?

[bluemoon288]

Can you actually "run" a real hotel with this program? In the EU / Germany?

[telivity-otaip]

Thats exactly what it was built for. I am deploying it for a 100 room hotel in Croatia as we speak.

[bluemoon288]

Hi everyone,

I am trying to test the project locally on a Windows machine using Docker, but I've run into a couple of roadblocks and could use some guidance.

1. Local Setup Issues (Windows + Docker)
   Stuck on Sample Data: When I spin up the containers, the setup seems to "hang" or freeze when attempting to load the sample data. It doesn't seem to complete, and I suspect there might be an error under the hood.

HAIP "Offline" Additionally, HAIP is reporting that I am "offline,". I am unable to select a property/accommodation.

2. Evaluating the Cloud Version

What are the main advantages of using the Cloud version over a local installation?

If I switch to the Cloud, how would I go about setting up our own hotel (property) there?

3. Offering Help with Translations
   On a side note, I really like this project and would love to contribute! I noticed some areas that could use translation support. What is the best way for me to help out with translations (e.g., German)? Should I look into specific language files, or do you use a platform like Weblate/Crowdin?

Thanks in advance for your help!

[telivity-otaip]

`

Hi @bluemoon288 — thanks for the detailed write-up, and great to hear you're enjoying the project! Good news up front: the first two problems are the same issues you reported earlier (#87 and #88), and both are already fixed and merged on main (#89 and #90). What you're seeing now is almost certainly an out-of-date checkout. Here's how to get unstuck, plus answers on cloud and translations.

1. The "hang on sample data" and "Offline" are the same root cause

These are linked: the sample data isn't loaded automatically by docker compose — it's a manual seed step — and the dashboard reports "Offline" simply because the database has no property yet. The dashboard only opens its live (WebSocket) connection after a property is selected, so an empty DB always shows as Offline. Once the seed runs and a property exists, it flips to Live. (Auth is off by default, so Keycloak isn't blocking the property list.)

The reason it hangs on Windows specifically is the CRLF line-ending issue you reported in #88: if the Keycloak init script is checked out as CRLF, Postgres can't run it (/bin/bash^M: bad interpreter, exit 126), the container never becomes healthy, and the seed step hangs waiting on the database.

2. How to fix it — re-clone, then follow the corrected order

Important: the .gitattributes fix from #90 only normalizes line endings on a fresh clone. A plain git pull won't rewrite the .sh files Git already checked out as CRLF on your machine — so please re-clone (or force a renormalize):

git config --global core.autocrlf false

# Re-clone fresh:
git clone https://github.com/telivity-otaip/haip.git haip-fresh
cd haip-fresh

# (Or, to fix your existing clone in place instead:)
#   git rm --cached -r . && git reset --hard

Then start up, waiting for the containers to be healthy before seeding:

docker compose up -d postgres redis keycloak
docker compose ps            # wait until all show "healthy"
docker logs haip-postgres    # confirm there's NO "bad interpreter / exit 126" error

pnpm install
cp .env.example .env
pnpm build
pnpm --filter @telivityhaip/database run migrate   # these scripts now exist (fixed in #89)
pnpm --filter @telivityhaip/database run seed       # creates "Telivity Grand Hotel"

pnpm dev                                            # API       -> http://localhost:3000
pnpm --filter @telivityhaip/dashboard dev           # dashboard  -> http://localhost:5173

Once the seed completes, the property selector populates with "Telivity Grand Hotel" and the status flips Offline -> Live. If the seed still hangs, paste the output of docker logs haip-postgres — it's almost always the container not being healthy.

3. Cloud version

There isn't a hosted/cloud version live yet, but it's close — we're targeting roughly a week out. It will be a paid offering (a fee to cover hosting infrastructure), as opposed to self-hosting which is free and open source. The main advantage will be convenience: no Docker, Postgres, Keycloak, migrations, or seeding to manage, and updates/backups handled for you. Functionally it's the same HAIP.

For evaluating right now, local is the way to go — but if you'd rather wait a week and try it hosted, that's a perfectly good option too. Once it's up we'll help you get your hotel set up; in the meantime (and on self-hosted), a property is created via the API (POST /api/v1/properties, admin role). Happy to share an example request if that's useful.

4. Translations — yes please, here's the best way

This would be hugely welcome. One heads-up so you don't waste effort: the app doesn't have an i18n framework wired in yet — the dashboard strings are currently hardcoded English, there are no locale files, and we don't use Weblate/Crowdin at the moment.

So the highest-value first contribution would be setting up the i18n foundation in the dashboard (e.g. react-i18next with src/locales/en.json + de.json) rather than translating existing files. If you open an issue or discussion proposing the approach, we'll align on structure before you invest time. German would be a perfect first locale — and the timing's good, since we just added a Germany/Berlin tax profile in #91.

Thanks again for digging in and for offering to contribute — let me know how the re-clone goes!

`

[bluemoon288]

Thank you so much for the detailed explanation! That makes perfect sense.

Regarding the i18n foundation: Since my background is on the hotel/business side rather than deep frontend architecture, I wouldn't want to mess up your repository's structure with a sub-optimal setup.

However, I would love to be your translation partner for the German locale!

Here is my proposal:
As soon as one of the core developers has time to set up the react-i18next foundation and creates the base en.json / de.json files, please let me know. I will gladly take care of translating all the dashboard strings into proper, hotel-industry-compliant German. I can either do this directly in the de.json file or via a spreadsheet, whatever is easiest for you.

Also, seeing that you just added the Germany/Berlin tax profile in #91 makes me even more excited about this project!

Let me know once the i18n structure is ready, and I'll jump right into the translations.

P.S. (On a side note with a wink): Are you absolutely sure you want Germany as your very first localized translated market? 😉

Joking aside, the German hotel market is a bit of a bureaucratic final boss. Between split VAT rates (7% for accommodation and breakfastmeal vs. 19% for breakfastdrinks (except for milk 7% VAT) /services), local city occupancy taxes (Bettensteuer), and the strict TSE fiscalization rules we mentioned earlier, it’s quite a ride.

That being yes, it’s also a huge market, and I’m more than happy to help you navigate these specific terminology and localization challenges so HAIP gets it exactly right!

[telivity-otaip]

`

This is exactly the partnership we were hoping for — thank you! And no worries at all about the frontend architecture; setting up the i18n foundation correctly is a core-team job, and you focusing on getting the German right is the perfect division of labor.

We're setting up the foundation right now. I'm wiring up react-i18next in the dashboard with src/locales/en.json and a de.json stub, and migrating the header/navigation first as the reference pattern so you can see how keys map to UI. I'll ping you the moment the PR is up — then you can translate directly in de.json (easiest for us to review via PR) or send a spreadsheet and we'll import it, whichever you prefer.

And honestly — your hotel/business-side perspective is worth more than frontend chops here. Hotel-industry-compliant German (the right terms for Anreise/Abreise, Meldeschein, Stornierung, folio vs. Rechnung, etc.) is exactly what generic translation gets wrong. So please flag anything that reads like software-translated nonsense.

On your wink 😄 — fair. Germany was less a grand strategic choice and more "the bureaucratic final boss volunteered to help us fight it." Between split VAT, Bettensteuer, and TSE, you're right it's a ride. But we actually see that as the point: the more challenging the market, the more valuable the solution becomes once it genuinely solves it. If HAIP gets Germany right, most of the rest gets easier — and having someone who understands the rules in the room is what makes it tractable. (Your milk-at-7%-vs-19% point is a perfect example — that nuance isn't fully captured in the #91 split yet, and it's exactly the kind of thing we'll want your eyes on.)

If you're up for it beyond translations, we'd genuinely value your review on the German tax/terminology side too — and I've opened a design spec for the TSE/fiscalization work at #104 if you want to weigh in there. No pressure; the German locale alone is a fantastic contribution.

I'll ping you as soon as the i18n PR is ready. Welcome to the HAIP Gemeinschaft — glad to have you building it with us and using it in production! FYI LLM as a channel integration incoming - you will be able to sell via ChatGPT and Claude soon.

`

[telivity-otaip]

`

The i18n foundation is up — you're clear to start! 🎉

PR: #105

Here's everything you need:

• Translate here: apps/dashboard/src/locales/de.json. It has the exact same keys as en.json — just fill in the German values. I've seeded a couple as examples (Reservierungen, Unterkunft auswählen); the rest are empty and waiting for you.
• Partial is fine: any value you leave empty falls back to English automatically, so the app never breaks while you work through it.
• Preview live: run pnpm --filter @telivityhaip/dashboard dev and use the new EN/DE switcher in the header to see your translations in context.
• Prefer a spreadsheet? Totally fine — translate key → value columns and send it over (or attach to a PR) and we'll import it.
• Guide: docs/i18n.md covers the workflow and conventions.

For now I've migrated the header and sidebar navigation as the reference pattern — that's a great first batch to get the terminology right (e.g. is it Übersicht or Dashboard, Zimmer vs. Räume, the right word for Folios/Front Desk/Housekeeping in proper hotel German?). We'll roll the rest of the screens into the same pattern and you can translate those as they land.

This is exactly where your hotel-industry perspective makes the difference — please don't just translate literally; use the terms a German hotelier actually expects to see. Open a PR or drop comments, whatever's easiest. Excited to see the first Deutsch land — danke! 🇩🇪

`

[telivity-otaip]

Noice. Allow me till tomorrow to respond to the deployment issues you opened. Should be able to take care of that for you.

[telivity-otaip]

the two PRs opened have been fixed.

Good feedback on tax rules and the split. Germany's reduced VAT on food (7%) vs standard on beverages (19%) is exactly the kind of jurisdiction-specific rule we built the tax engine to handle.
I'm adding split-component taxation right now — a single charge (like breakfast) gets split by configurable percentage (e.g., 70% food at 7%, 30% beverage at 19%). Also adding a full Germany/Berlin tax seed profile with accommodation VAT (7%), Übernachtungsteuer (5%, business traveler exempt), and the food/beverage split.
Should land tonight.
If you have other Germany-specific or other country requirements as you test, keep filing them — this is exactly the feedback that makes the system production-ready. What city is your hotel in? I'll make sure the tax profile matches your local rules.

[bluemoon288]

Thank you for your feedback. Our hotel is located in a small village. Therefore, there is no "Übernachtungsteuer", no "Kur-Taxe" or any other "special levy" payable to the town/city.

[telivity-otaip]

Done — split-rate VAT landed in c2de47b.
The tax engine now supports split_component rules. A single charge (breakfast, half board, full board) splits by configurable percentage with different VAT rates on each component.
I also added a full Germany/Berlin seed profile:

Accommodation: 7% reduced VAT
Übernachtungsteuer: 5% city tax (business travelers exempt)
Breakfast/meals: 70% food @ 7% + 30% beverage @ 19%
Services (minibar, spa, parking, etc.): 19% standard VAT

The 70/30 food/beverage split is configurable per property — if your hotel's breakfast has a different ratio, you can adjust it in the tax settings.
Pull latest and re-run the migrate + seed. Let me know what city your hotel is in and I'll add the local tax profile if it differs from Berlin.

[bluemoon288]

Sorry another Question:
Regarding German Fiscalization (TSE Interface)
We have to comply with the local KassenSichV (Kassensicherungsverordnung) regulations.

Does the system currently support a TSE (Technische Sicherheitseinrichtung) interface for legally compliant fiscalization?

If not, is there a recommended workaround, or is a TSE integration planned for future releases?

Germany is complicated.

[telivity-otaip]

`

Great question — and you're right that Germany is complicated. Honest answer:

No, HAIP does not currently have a TSE / KassenSichV interface. We have a tax-calculation engine (including a Germany/Berlin VAT profile as of #91), invoice rendering, and an immutable audit log — but none of that is certified fiscalization. KassenSichV needs a certified TSE that cryptographically signs every transaction in real time, DSFinV-K export for tax audits, receipt obligations (Belegausgabepflicht), and TSE-offline handling. That's a distinct, substantial piece of work, not just tax math.

It's firmly on our roadmap, but I won't give you a fake date — it's a meaningful build. Here's how we're thinking about it, so you can decide whether you'd like to help drive it or wait for us:

The plan

• You don't build a TSE — it must be BSI-certified. The work is integrating a certified provider: cloud (fiskaly SIGN DE, Deutsche Fiskal) or hardware (Epson/Swissbit). It fits our existing channel-adapter pattern.
• Architecture: bring-your-own-TSE-credentials, per property. A production TSS is registered to a specific taxpayer, so each hotel supplies its own provider credentials in config — HAIP signs against them. This is both the legally correct model and the cleanest design (the project never owns anyone's fiscal data).
• Scope: (1) provider client + per-property TSS config + signing hooked into folio/payment finalization + receipt fields/QR; (2) DSFinV-K export; (3) offline buffering, counter-gap detection. Roughly a week-plus of build for a sandbox-validated integration.
• What code alone can't deliver: legal sign-off. The certified TSE is the provider's; the overall setup still needs a Steuerberater review + Verfahrensdokumentation (GoBD). We'll provide a docs draft, but production compliance is validated by the deploying hotel's tax advisor.

If you'd like to contribute (we'd love that)

• You can build against a free sandbox account from a provider like fiskaly — no contract, no cost, no legal exposure. If you have or can grab a sandbox key, that's a perfect starting point.
• Production accounts are each hotel's own — never yours or the project's — so contributing carries no liability for you.
• We'll open a design issue with the data model, the exact transaction trigger point, and the DSFinV-K mapping for you to review/build from, and we'll support and review the PR closely. Your understanding of the German requirements would be hugely valuable here.

If you'd rather wait

Totally fine — it stays on the roadmap and we'll build it ourselves; just no committed date yet. If you're evaluating in the meantime, the rest of HAIP (reservations, folios, tax, channels) runs independently of fiscalization.

Let me know which way you're leaning — happy to spin up the design issue either way so the plan is public.

`

[telivity-otaip]

@bluemoon288 did you see the PR 110? Also - module for media, user/roles/ couple of adapters - added to the platform

[bluemoon288]

Where? 3 Days old no update?

[telivity-otaip]

#110

[telivity-otaip]

These should make you happy

https://github.com/TelivityAI/haip/releases/tag/v1.3.1

https://github.com/TelivityAI/haip/releases/tag/v1.3.0

https://github.com/TelivityAI/haip/releases/tag/v1.2.9

[bluemoon288]

today i made some changes in
haip/apps/api/Dockerfile

# #

Install All Workspaces total

RUN pnpm install --recursive

build Shared-Package

RUN pnpm --filter @telivityhaip/shared run build

#build Database-Package
RUN pnpm --filter @telivityhaip/database run build

and it run at my system.

I was able to create a "new" hotel, (localhost:3000) but unfortunately not a room category, etc. I’m curious to see how the software develops.
On another note: There are hotels, guesthouses, etc., that don't have a star rating—so why does an error message appear?

If HAIP is usable for us, I’ll test it thoroughly. To do that, though, I’d first have to set everything up—rooms, etc.
The guest data is a bit sparse—just for reference: is it the address, a company address, or a billing address?

[telivity-otaip]

`

Hi @bluemoon288 — merged the German update PR. Thank you for contributing. 🙌

I think you found a real bug: the "Add room type" form wasn't sending a field the API requires, so it rejected every attempt. Fix incoming, and I'll tag you when it lands so you can confirm.

Now let me make you a proper offer, because you've earned it:

Come be one of our founding pilot hotels. Here's what that means for you, concretely:

• We do everything for you. I set the whole thing up in the cloud — your hotel fully configured, your booking website deployed, integrations connected, and the AI admin copilot helping you manage it. No Docker, no Dockerfile edits, no infrastructure. You just log in and test it out.
• Our local AI enabled on your property — the piece that explains and sharpens pricing, overbooking and cancellation decisions, running privately.
• Completely free — and not "free trial then we bill you." Founding pilots get everything free for a year. When the pilot ends, we hand it over to a cloud account of your choice with all your data, so you can keep using it, building on it, and playing with it.
• You're already helping shape it — what you flag gets fixed, and you'd be first to test what's next.

I'm taking on just 5 pilot hotels right now, deliberately small so each one gets hands-on attention and helps us harden and polish the platform. Given how deep you've already gone — and that you're our German-speaking contributor — I'd love for you to have one of those spots, with the German UI you're helping build.

If you're interested, email me and I'll get you set up — I dropped you my email directly so we can take it from there.

— D

`

[bluemoon288]

Hi, and thank you again for your generous offer — I truly appreciate the trust and the opportunity.

I want to support the project and contribute meaningfully, but I also need to be honest about the operational realities on our side. Running two systems “live” in parallel is extremely challenging for a hotel. Every booking, charge, invoice, and operational action inside HAIP would have to be mirrored in our currently running system.
For that reason, a full switch would only be possible once HAIP is 100% stable in daily operations.

I also have a few fundamental questions about the long‑term direction:

Will HAIP become a fully functioning open‑source project (with your optional paid hosting), or will it remain a “find the stumbling blocks” project that ultimately leads into the paid model?
I ask this not critically, but because clarity here is essential for planning and for understanding how independent and sustainable the open‑source version will be.

This point matters especially because small, family‑run hotels urgently need a complete, affordable system — including inventory, ordering, housekeeping, packages, catering, and more. For many of them, a reliable open‑source solution could make a real difference.
And equally important: direct bookings. Platforms like Booking.com take a significant share of revenue, so having a strong, integrated direct‑booking engine is crucial for small hotels to survive.

If HAIP is intended to be true open source, then — due to time constraints and the realities mentioned above — I would approach testing in a structured, step‑by‑step way:
starting from zero, building up to a fully running hotel environment, and documenting everything.
This would include practical workflows such as ordering goods (e.g., bakery items for breakfast), external laundry services, inventory management, packages, catering, Lost & Found, and anything else that comes up.

If the system meets our requirements, I would then set it up again from scratch and run it “live” for about one month — with our existing software still running in parallel. If HAIP proves stable, correct, and easy to operate even for "inexperienced" staff would a full switch be possible.

My intention is not to reject your offer — quite the opposite. I want to support the project and help shape it, but with a clear focus on making HAIP a robust, usable open‑source solution that small hotels can truly rely on.

Let me know how you see the open‑source roadmap and whether this structured testing approach aligns with your plans.

[telivity-otaip]

Hi,

Thanks — the German PR and the room-type bug report were genuinely useful contributions.

Your main question, directly: HAIP's core is open source — free, complete, Apache 2.0, permanently. Self-hosting is fully supported — it's what HAIP is built for. The managed service — hosting, labor, the AI model, and the compute behind it — is the premium path; that creates real costs and requires charging to cover them. It exists because of the demand we've seen since announcing. No bait and switch, no funneling — just cost allocation.

On inventory, ordering, catering, Lost & Found: straight answer — those aren't built and aren't on my roadmap. They're ERP territory, not PMS core. Vendor spend already works as charges or a vendor house-account, as with most PMS, and rate plans cover common package cases. If custom workflows matter to your hotel, the door is open to contribute them and I'll review and merge whatever we agree is a high-quality addition — but I can't commit to building ERP features into the PMS.

The part that matters most: the reason you couldn't add or delete anything was a real bug — the dashboard was sending data the API rejected — and it's now fixed. The core runs end-to-end: reservations, rates, guests, check-in/out, folios, payments, housekeeping, night audit, direct booking widget, plus CSV import/export for migrating off a legacy system. For a standard front-office PMS switch, your plan — import, configure, parallel run, cut over — is exactly right, and that should be days to a couple of weeks, not months.

One clarification on what I offered: the open-source HAIP is what you already forked — including the 12 AI agents that help you optimize and run the system — and you can test it today. The pilot is early access to our managed hosted version with the AI copilot; that is a commercial layer and won't be open-sourced. Open source gives you all the tools to apply your own knowledge, experience and make it yours; the commercial layer is renting our knowledge, experience and infrastructure. Hope that clarifies.

Best!
D