Skip to main content
Self-hosting AppBlips puts you in full control of your data, your AI keys, and your infrastructure — but it also means you own the security posture of your installation. This page covers the key security boundaries to understand before you expose AppBlips beyond localhost, so you can make informed decisions about access control, key handling, and network exposure.

​
The Builder API Has No Authentication

In self-hosted mode, the /api/chat endpoint accepts every request as the same local user — there is no login check and no per-user isolation. Anyone who can reach the endpoint can spend your configured AI budget. Do not expose AppBlips directly to the internet without putting your own access control in front of it first. A reverse proxy with HTTP basic auth, a VPN, or firewall rules limiting access to trusted IP ranges are all practical options.

​
Sandboxed Preview

Generated apps never run directly inside the main AppBlips page. Every generated app executes in a fully isolated preview environment, which means:
  • The generated app cannot access the parent page’s DOM, cookies, or localStorage
  • The parent page cannot reach into the generated app’s DOM
  • The generated app cannot make credentialed requests that carry your AppBlips session
This isolation is the primary protection against malicious or buggy generated code affecting your AppBlips session. It applies both in the live preview and when you open a saved app for review.

​
BYOK Key Storage

In the default byok mode, each person using a generated AI-enabled app is prompted to enter their own provider endpoint, model name, and API key the first time AI is needed. AppBlips handles this key as follows:
  • The key is stored in the browser only — in sessionStorage by default, or localStorage if the user checks Remember on this device
  • The key is never sent to your AppBlips server at any point
  • The key is never embedded in the generated HTML when an app is exported
While a generated app is running and connected to AI, JavaScript executing inside that app can access the key in order to make AI calls via blip.ai.text(...). Advise users not to enter high-privilege or shared API keys into generated apps, and to prefer keys with spend limits or scoped permissions from their AI provider.

​
Relay Mode Security

When you set APPBLIPS_GENERATED_AI_MODE=relay, your server acts as a proxy between generated apps and your AI provider. The provider key never leaves the server — the browser only receives the relay URL. This removes the need for users to supply their own keys, but it shifts the billing and access control responsibility entirely onto you.
The built-in per-IP rate limiter (APPBLIPS_APP_AI_RATE_LIMIT_MAX / APPBLIPS_APP_AI_RATE_LIMIT_WINDOW_SECONDS) is a speed bump against runaway usage, not a billing boundary. It resets on restart and offers no protection against distributed clients. For any installation accessible beyond localhost, put a real authentication layer or API gateway in front of the relay endpoint before going live.
If apps generated by your instance are served from a different origin than AppBlips itself, set APPBLIPS_APP_AI_ALLOWED_ORIGINS explicitly to the exact origins you want to permit. Leaving it blank allows only same-origin callers. Do not add origins you do not control, and avoid adding null unless you specifically intend to serve apps as local file:// pages.

​
Hosting Exported Apps on a Separate Origin

If you self-host AppBlips and also plan to host exported apps somewhere publicly accessible, serve the exported apps from a different domain or subdomain than your AppBlips instance. Generated apps are self-contained HTML with full script privileges, so keeping them on a separate origin limits what a compromised or malicious app can access from your AppBlips installation.
  1. Keep AppBlips behind localhost or a firewall unless you have added explicit authentication in front of it. The /api/chat endpoint has no built-in auth.
  2. Use HTTPS if AppBlips is reachable over any network. Terminate TLS at a reverse proxy such as Nginx or Caddy and proxy to AppBlips on port 3000.
  3. Set APPBLIPS_APP_AI_ALLOWED_ORIGINS explicitly if you run in relay mode and any generated apps are served from a different origin. List only the exact origins you control.
  4. Monitor your AI provider’s usage dashboard regularly for unexpected spend — especially after any change to rate limit settings or network exposure. Provider-side spend limits are an additional safeguard worth enabling.