Legal template

Privacy Policy

A simple privacy template for DevFrame deployments, written around the current Clerk, Supabase, preview-cookie, upload, and public portfolio architecture.

Terms Cookie Policy

DevFrame system map

The same App Router shell powers marketing, Studio, Builder, Dashboard, and public portfolio routes.

Runtime

Next.js App Router

Server components first

Output

/p/[slug]

Shareable portfolio routes

Data

Single record

Template swaps preserve content

Fallback

Demo mode

Works without full setup

Template notice

Review before production use

This privacy policy is a general template for the DevFrame project and should be reviewed by a qualified professional before production or legal use.

It is not legal advice.

Update it for your deployment, jurisdiction, analytics choices, and data processors.

Account data

Authentication information

When Clerk is configured, DevFrame uses Clerk for sign-in, sign-up, OAuth, session handling, and account identity.

DevFrame reads the authenticated user id to associate one portfolio record with its owner.

Custom auth screens are part of DevFrame, but session infrastructure is handled by Clerk.

If Clerk is not configured, demo mode uses a synthetic local viewer for preview workflows.

Portfolio data

Published portfolio content

When Supabase is configured, portfolio content is stored so it can render on public routes like `/p/[slug]`.

Portfolio fields can include name, title, location, email, bio, skills, links, projects, experience, sections, template settings, and assets.

Published public portfolio pages are intended to be visible to anyone with the route.

Preview fallback data may be stored in a secure cookie when Supabase persistence is not available.

Uploads

Image and asset handling

Profile and gallery images may be uploaded to Supabase Storage when uploads are configured.

DevFrame validates allowed image types and file size limits before upload.

Server actions save URLs and storage paths rather than raw image blobs.

Template switches preserve profile and gallery assets under the single-record persistence model.

Diagnostics

Operational data

DevFrame may process basic request context to protect save actions and diagnose setup readiness.

Rate limiting can use in-memory development fallback, Upstash Redis, or Vercel KV-compatible variables.

Setup diagnostics should only be exposed when explicitly enabled.

This template does not claim that analytics or tracking are enabled by default.

Choices

Managing data

Production deployments should provide clear account, portfolio, and deletion workflows based on their actual configuration.

Users can edit portfolio data through Studio or Builder.

Account management depends on the configured Clerk project.

Portfolio storage and retention should be documented for the specific deployment.

This page is general placeholder legal copy. Review and adapt it before using DevFrame in production or presenting it as your final legal policy.