Libraries
@veltdev/react@veltdev/client@veltdev/sdk
July 9, 2026
New Features
- [Self-Hosting]: New optional
selfHostedblock oninitConfiglets 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, orstrict: truefor 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 aselfHostedblock behaves exactly as before. Learn more →
- React / Next.js
- Other Frameworks
-
[Self-Hosting]:
Velt.loadVelt()andVelt.loadSnippyly()now accept an optionalconfigargument with the same shape asinit(), so manual-loader flows can injectselfHosted.firebaseConfigbefore the default Firebase app bootstraps. Backward-compatible — a bareloadVelt()/loadSnippyly()call behaves exactly as before. -
[Self-Hosting]: The
Configmodel gains an optionalselfHostedfield, backed by new public typesSelfHostedConfig,SelfHostedCloudFunctionConfig, andDeploymentModuleId. 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 concurrentinit()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 laterloadVelt(config)/loadSnippyly(config)can still inject itsselfHostedconfig 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 andinitConfigsupply diverging configs, instead of failing silently on this split-brain state.

