---
title: "How it works"
description: "Architecture, functionality and supported services of the meinGPT Outpost"
canonical_url: "https://meingpt.com/en/docs/integrations/vault/how-it-works"
language: en
---

# How it works

The Outpost stores and processes your data within your own infrastructure; what leaves it for search and answer generation is only what the release level set per folder allows — text excerpts by default, plus the original file if you enable that. This page describes the mechanism behind that — what an Outpost is and what you manage in meinGPT is in the [Outpost overview](/en/docs/admin-guide/outposts).

## Connecting via the Bridge

Your Outpost connects to meinGPT through the **Bridge** — an outbound, encrypted connection that the Outpost itself opens to meinGPT. Because the connection is established from the inside out, you don't need to **open any inbound firewall ports, provide a public IP address, or expose a reverse proxy**. Your Outpost stays entirely inside your own network.

### How an Outpost joins

There is **no discovery**. The only thing the Outpost is told is the address of your meinGPT instance. Everything else the two sides negotiate between themselves.

| # | Who | What |
| --- | --- | --- |
| 1 | Person at the machine | enters the meinGPT address in the Outpost. `https://` is allowed anywhere, `http://` only on `localhost` |
| 2 | Device | generates an Ed25519 key pair **locally**. The private half goes into the operating system's key store and never leaves the machine |
| 3 | Device → platform | registers the **public** key along with installation ID, hostname, operating system and version. The platform creates a session bound to exactly that key and answers with two codes: one the device keeps, and an **eight-character one for the screen** |
| 4 | Device | polls every five seconds — and **signs every poll**. Until approval the answer is “not authorised yet” |
| 5 | Admin in meinGPT | compares the **fingerprint phrase** shown against the one on the device's screen, gives it a name and approves the device. If two admins approve the same code at once, exactly one wins; the other is told |
| 6 | Device → platform | the **next signed poll** activates the key — in *one* transaction: every previously active key of this Outpost is revoked, the new one is created, the session is consumed. Back comes the configuration: organisation, Outpost ID, endpoint, platform public key, bridge address |

**The code alone is not enough — the fingerprint phrase is the check**

The code only identifies the session; it would be just as valid for a
different machine that happened to pair at the same moment. Only comparing
the fingerprint phrase tells the admin they are really approving this
device.

**Approval alone activates nothing**

Only the signed poll does. A machine that cannot sign is not the machine that
asked — the code on the screen is a session handle, not a secret. Someone who
reads it off the screen but does not hold the private key gets the same answer
as someone holding nothing.

From then on **no reusable secret is on the wire**: every call in both directions carries its own signature. Details in [Security](/docs/integrations/vault/security).

### When an Outpost has to pair again

The most common case is not one: if the machine merely loses its connection — network gone, machine switched off — it keeps its key and comes back on its own. There is nothing to do.

If the **key** is gone — reinstall, new disk, factory reset — the same sequence runs again: new key pair, new code, approval **for the same Outpost**. Step 6 replaces the old key with the new one.

**Shares survive a re-pairing**

Folders, adopted collections and permissions hang off the **Outpost**, not off
the key. Pairing again only swaps the machine's identity; none of it has to be
set up a second time. The old device is refused afterwards — without being told
why.

## How It Works

### Data Pool Synchronization

The Outpost synchronizes data from various supported services and processes them for AI-powered analytics:

Secure and encrypted transfer from various sources

Splitting into chunks and conversion to embeddings

Embeddings are stored in a local vector database

Relevant data sections are identified for AI responses

Cloud AI processes only the relevant text sections

### Search and Query Processing

User queries are sent to the cloud platform

The Outpost searches the local database for matching sections

Only relevant text sections are encrypted and transmitted to the cloud

The AI generates precise answers based on these sections

## Supported Services

### Collaboration

Microsoft SharePoint, OneDrive, Google Drive

### Cloud Storage

Amazon S3 and S3-compatible endpoints

### Local Files

Local folders, SMB network shares, WebDAV

### Databases

PostgreSQL, MySQL, Microsoft SQL Server — only with the services preview enabled

Which of these sources need an Outpost and which meinGPT connects directly, in detail: [Data sources](/en/docs/integrations/vault/sources).

For questions and further support, please contact our
technical team at [support@meingpt.com](mailto:support@meingpt.com)