> ## Documentation Index
> Fetch the complete documentation index at: https://larkup.de/documentation/llms.txt
> Use this file to discover all available pages before exploring further.
# Deploy Your Server
> Launch locally, deploy to a cloud provider, or export a portable server.
Larkup can run the retrieval and chat API locally or deploy it to a cloud provider. Open **Settings → Larkup Server** to manage both paths.
## Launch and test locally
Go to **Settings → Larkup Server**. When the server is stopped, select **Launch server**.
After launch, the page shows the local endpoint, server API key, SDK connection action, test action, and interactive API reference.
The app assigns an available workspace port starting at `8080`. A generated standalone server uses `8080` by default.
Use **Try it**, open **API reference**, or run:
```bash theme={null}
larkup test --endpoint http://localhost:8080
```
## Deploy from the Web UI
Select **Deploy** to choose Vercel, Hetzner, Azure, AWS, GCP, DigitalOcean, or another available target.
### Vercel
Select **Deploy → Vercel** from the server page.
Paste your Vercel token and a project name, then verify the connection.
Confirm the embedding model, then choose the **AI chat runtime** for this deployment. It uses the Project provider by default and can be overridden with OpenAI, DeepSeek, Google, Mistral, Cohere, or Vercel AI Gateway. Review the environment values, including the server API key.
Local LanceDB files are not durable on a serverless deployment. Use Pinecone, LanceDB with S3 compatible storage, or another persistent provider when the deployed server includes the knowledge base.
Select **Deploy Server**. Larkup opens the **Cloud deployments** tab when the request is accepted, where you can follow the provider status and open the API endpoint.
### VPS and other cloud targets
Choose the provider from the same **Deploy** menu. For an SSH target, provide the host, user, authentication method, and required environment values. Larkup builds the server, launches it through Docker, and returns the deployed endpoint.
Put a reverse proxy such as Caddy or Nginx in front of a public VPS endpoint to provide HTTPS and a custom domain.
## Deploy from the CLI
Generate a portable artifact:
```bash theme={null}
larkup deploy docker --out ./deployment
larkup deploy vercel --out ./deployment
```
Start locally or create the agent server target:
```bash theme={null}
larkup deploy local
larkup deploy agent
larkup deploy agent --start
```
After deployment, verify the endpoint:
```bash theme={null}
larkup test --endpoint https://your-server.example.com \
--api-key "$LARKUP_API_KEY"
```
## Before going live
* Set a strong server API key.
* Use persistent storage for the deployed knowledge base.
* Add the model, embedding, and storage credentials required by your configuration.
* Keep secrets in the deployment provider rather than source control.
* Test the health, query, chat, and API reference endpoints.
The generated output is a standard Node.js server and includes a `Dockerfile` and `vercel.json`.
## Create a chat assistant for your website in minutes
Once your server is running, open **Settings → Larkup Server → Connections → Chat Widget → Customize**.
### Customize the appearance
Set the title, welcome message, placeholder, accent colour, position, and dark mode. Save, then restart the local runtime or redeploy to publish the update.
This is what it looks like running on a page:
### Embed it
The same page gives you a ready to copy script using your server's URL:
```html theme={null}
```
The generated server owns `/widget.js` and `/chat`, so the widget works the same locally, in Docker, and after deployment. It renders inside a Shadow DOM to keep its styles separate from the host site.
Individual embeds can override the generated defaults:
```html theme={null}
```
`data-class` is applied to the widget's outer mount. The chat interface itself is intentionally isolated, so host Tailwind classes cannot accidentally break the embedded UI.
### Security
`data-api-key` is readable by every visitor to the page. Use a scoped, low-privilege retrieval key for a browser widget, or put a small authenticated proxy in front of the Agent server for production sites. Never embed an admin, ingest, model-provider, sandbox, or Marketplace credential in client code.
The same key is available behind a reveal/copy control in the Larkup Server screen only for the current browser session. Use it server side for production calls, where the key stays private.
### React
Load the same script once in a client component:
```tsx theme={null}
'use client';
import { useEffect } from 'react';
export function SupportWidget() {
useEffect(() => {
const script = document.createElement('script');
script.async = true;
script.src = 'https://your-agent.example.com/widget.js';
script.dataset.apiKey = process.env.NEXT_PUBLIC_LARKUP_WIDGET_KEY!;
document.body.appendChild(script);
return () => window.LarkupWidget?.destroy();
}, []);
return null;
}
```
Prefer a proxy or a purpose-made retrieval key rather than exposing a general server key through a `NEXT_PUBLIC_*` variable.