GitLab

GitLab tends to be chosen for control: a company that wants its source on its own infrastructure, or one whose CI and code live deliberately in the same place.

Property groups that own their booking platform sometimes fall into that category, particularly where a data protection requirement makes self-hosting the simpler answer than a policy argument.

Connecting GitLab gives that team the same conversational reach as everyone else — what is open, what is waiting, what changed — without asking them to abandon the setup they chose for good reasons. Like the rest of this category, it serves your engineers rather than your operations.

The practical test is whether anyone in your company writes code. If nobody does, skip this one — there is no property-management benefit hiding underneath it, and a page that pretended otherwise would be wasting your time.

Once GitLab is connected, ProhostAI works with your projects, issues and merge requests in plain language.

Read

• Search projects Find code and history across the projects the connected account can reach. "What is waiting for review on the portal project?"
• Review issues and MRs See what is open and what has stalled.

Create & update

• Create and update issues Raise or update issues as work is identified.
• Comment on merge requests Leave a note without switching context.

GitLab connects through OAuth, against gitlab.com or a self-hosted instance reachable from the internet.

1. Open ProhostAI and go to Settings → Connections.
2. Search for GitLab and select Connect.
3. Sign in to GitLab and approve the permissions.
4. Ask what is open on one of your projects to confirm it works.

• Self-hosted instances work, provided the instance is reachable from the internet for the OAuth flow.
• Access follows the connected account’s project permissions.
• This is a tool for your engineering team rather than property operations.