Skip to main content

Libraries

  • @veltdev/react
  • @veltdev/client
  • @veltdev/sdk
July 9, 2026

New Features

  • [Self-Hosting]: New optional selfHosted block on initConfig lets you redirect Velt’s backend endpoints (Firebase config, cloud-function URLs, notifications RTDB URL, encrypted-write endpoints) to your own infrastructure. Use the default hybrid mode to migrate one endpoint at a time, or strict: true for full data-sovereignty mode where any un-provided endpoint resolves to an inert sentinel with zero egress to Velt. Every field is optional, so a config without a selfHosted block behaves exactly as before. Learn more →
  • [Self-Hosting]: Velt.loadVelt() and Velt.loadSnippyly() now accept an optional config argument with the same shape as init(), so manual-loader flows can inject selfHosted.firebaseConfig before the default Firebase app bootstraps. Backward-compatible — a bare loadVelt() / loadSnippyly() call behaves exactly as before.
  • [Self-Hosting]: The Config model gains an optional selfHosted field, backed by new public types SelfHostedConfig, SelfHostedCloudFunctionConfig, and DeploymentModuleId. Additive only — existing configs typecheck and behave unchanged. Learn more →

Bug Fixes

  • [Self-Hosting]: Each Velt.init() call now owns a private polling timer and retry counter instead of sharing module-level state, so repeated or concurrent init() calls can no longer overwrite each other’s timer handle or corrupt the shared retry budget.
  • [Self-Hosting]: A failed or timed-out init() now cleanly releases its pre-bootstrap stash authority, so a later loadVelt(config) / loadSnippyly(config) can still inject its selfHosted config on the same page load.
  • [Self-Hosting]: loadVelt() / loadSnippyly() now stash the pre-bootstrap self-hosted config and emit a specific console warning when a manual loader and initConfig supply diverging configs, instead of failing silently on this split-brain state.