Where data belongs
Data Surfaces
Vibecodr data surfaces differ by job: operation memory, app records, public display, uploaded files, and connected provider state.
Data-surface decision guide for Vibecodr apps and Pulses.
Implementation focus
Use this before storing app data, choosing `env.db`, adding public metadata, or deciding whether Pulse State is the right tool.
Expected outcomes
- Use Pulse State only for operation coordination.
- Use `env.db` or external services for durable app records.
- Keep public metadata limited to public description.
- Avoid using public asset URLs as authorization checks.
Choose by data job
Vibecodr has several data surfaces because not all data has the same job. Pulse State coordinates operations. `env.db` can support eligible SQL-shaped app data. Public media and runtime files support display and playback. External services remain the right home for provider-owned records.
The safe choice starts with the consequence: duplicate prevention, app query state, public display asset, uploaded project bytes, or third-party account data. Once the job is clear, the surface usually becomes clear too.
- Use Pulse State for operation lifecycle and duplicate protection.
- Use `env.db` for eligible app data that benefits from SQL reads and writes.
- Use storage/media lanes for files and assets, not queryable app records.
- Use external services for provider-owned records and account-specific resources.
Keep public metadata public
Public metadata should explain a vibe, not store sensitive app state. Titles, descriptions, tags, covers, and social context help people find and understand work, but they are not a private data store.
If data is user-specific, credential-bearing, sensitive, or expected to change through backend logic, put it in the correct trusted surface instead of hiding it in a post description, tag, query string, or client bundle.
- Do not store tokens or private user records in public metadata.
- Do not use Pulse State as a long-term app database.
- Do not use public asset URLs as permission checks.
- Document what the vibe stores and where when users need to trust it.
Example and read next
Example: a Pulse needs to avoid duplicate webhooks and also store app records. Use Pulse State for duplicate memory, env.db or an external service for records, and public metadata only for public description.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Pulse State
- Read next: Storage Lanes
- Read next: Secrets & APIs
- Read next: Connections