Your Office Harness, on your own terms
Self-hosting the Microsoft 365 add-in for teams
By OpenDocBot · November 11, 2026
OpenDocBot is a Microsoft 365 add-in for Word, Excel and PowerPoint. It already runs client-side, so your documents go from Office to the model provider you choose, not through us. Self-hosting is about a different kind of control: where the add-in is served, who can open it, and what settings everyone gets.
For a team, that difference matters. The hosted add-in is easy to try. A self-hosted instance is something IT can put behind the company domain, the company identity provider and one shared configuration.
What self-hosting changes
Your server
Office loads the add-in from your hostname. You choose the network, the certificate and when to update.
Your identity provider
Put the add-in behind Entra ID, Okta, Keycloak, Auth0 or Google. Only the groups you allow can open it.
Your configuration
Set the provider, model and API key once. Every user gets the same managed setup, with no manual configuration.
Same product, not a different edition
Self-hosting is not an enterprise-only build. The same add-in runs on your infrastructure. Teams of up to 30 users can use it for free, including SSO and managed configuration.
The server is the control plane, not a mandatory data path. It serves the add-in, handles sign-in and delivers configuration. Model requests still go from the user's Office client to the provider you configure. If you need to route model traffic through your own gateway, the optional proxy is there. Most teams start without it.
> deployment flow
>1/3Serve the add-inOffice loads OpenDocBot from your hostname.
One script, one working instance
The repository includes a guided setup script. Clone the repo, run it, and answer a few questions.
bash
git clone https://github.com/OpenDocBot/OpenDocBot.git
cd OpenDocBot
./setup.shopendocbot setup
The wizard does five things:
- Address and certificate. It detects the hostname or IP, asks for the port and generates a self-signed certificate unless you provide one.
- Configuration. It writes
.envwith a strong session secret and, if you want, SSO settings. Managed configuration is a separate.envsetting added after setup. - Manifest. It builds
dist/manifest.xmlfor your hostname. - Summary. It shows the URL, certificate, environment file and manifest path.
- Start and verify. It starts Docker Compose, waits for the health check and confirms that HTTPS answers.
It asks only for what it needs. For an internal runbook or automation, the non-interactive form takes the same values up front:
bash
./setup.sh --yes --host addin.example.com \
--cert /etc/letsencrypt/live/addin.example.com/fullchain.pem \
--key /etc/letsencrypt/live/addin.example.com/privkey.pemFor a pilot, the generated self-signed certificate is fine. For production, pass a certificate your clients already trust. If the certificate is self-signed, the script prints the trust commands for Linux, Windows, macOS and Chromium Snap.
What the script writes
| File | Why it matters |
|---|---|
certs/addin.crt | The certificate Office loads. The script generates it or installs the one you pass. |
certs/addin-key.pem | The matching private key. It stays in certs/ and is not committed. |
.env | Port, session secret and optional SSO settings. Managed configuration can be added later. Written with mode 0600. |
dist/manifest.xml | The file you upload to the Microsoft 365 admin center. It points Office at your hostname. |
Everything lives in the repository root, so backups and migrations are straightforward.
After setup: manifest, SSO and managed configuration
Three steps remain:
- If the certificate is self-signed, trust it on every client that opens the add-in. The script prints the exact commands.
- Upload
dist/manifest.xmlto the Microsoft 365 admin center, then assign the add-in to users or groups. - If you skipped SSO in the wizard, add the
OPENDOCBOT_OIDC_*settings to.envand restart. To set the provider, model and API key once for everyone, addOPENDOCBOT_MANAGED_CONFIGorOPENDOCBOT_MANAGED_CONFIG_FILEto.envand restart. Managed configuration requires SSO.
The self-hosting guide covers certificate trust, renewal, the manual Docker path, Node and static hosting. The SSO and managed configuration guides cover the team settings.
Who this is for
Self-hosting fits teams that already run internal infrastructure and need one or more of these:
- A company hostname instead of a shared public endpoint.
- Sign-in through the company identity provider.
- One approved provider, model and API key for everyone.
- A deployment their security team can review and operate.
If you just want to try OpenDocBot, install it from the Microsoft Marketplace. Self-host when you need the control surface.
OpenDocBot does not mark up model usage; you pay your provider directly. Self-hosting, SSO and managed configuration are included in the free tier for up to 30 users. Above that, a commercial license covers usage rights and support, not a different feature set.
What's next
If you want a hand with the first deployment, tell us at hello@opendocbot.com.