Encryption is expected for sensitive data
Transport should run over TLS and sensitive stored values should be encrypted at rest with rotated keys. Signed webhook payloads and audit-chain hashes help detect tampering.
Security
Your code, integrations, and operator workflows should stay controlled.
Potsticker.AI is being hardened to keep repo access, integrations, and AI operations deliberate instead of vague or accidental.
Soft launchFounding accessBuyer-ready docs
Why this matters
Early buyers should not have to guess how the product is run.
Potsticker.AI should make its access model, privacy stance, and commercial boundaries obvious before a buyer ever has to book a call or email your team.
Clear boundaries for publishing, billing, and customer data.
A trust surface that matches the quality of the product itself.
Enough clarity for buyers, partners, and operators to move forward with confidence.
Security
Security
Platform protections, publishing boundaries, and operational safeguards.
Privacy
Privacy
How access, customer data, and account activity are handled.
Terms
Terms
The commercial baseline for using the product in a real business setting.
Your code stays private by default
Potsticker.AI does not require making your repositories public. Repo integrations use tokens you control, and the system reads provider metadata from repos you already own.
Proposal-first and guarded operations
The platform is designed around read-first, proposal-first, and controlled execution patterns. Protected zones, allowed roots, and rate limits exist to keep automation from becoming reckless.
Integrations are explicit, not magical
Billing, analytics, deploy, incident, publishing, and repo integrations only work when you deliberately connect them with your own keys, tokens, or webhooks.
Soft-launch access is intentionally staged
Current access is invite-led and staged carefully. We keep rollout deliberate while production persistence, trust surfaces, and onboarding continue to harden.
Code and repo boundaries
Private repo integrations do not make your code open source.
Allowed roots and protected zones constrain repo-facing operations.
Many workflows are preview-first or proposal-first instead of direct write paths.
Secrets and integration control
Tokens and keys are provided by the operator through local or hosted environment variables.
Sensitive integration credentials should be encrypted at rest and rotated on a fixed schedule.
Webhook and connector payloads should be signed and verified before data is accepted.
Publishing, billing, analytics, incident, and repo integrations are off until explicitly configured.
The system is designed so live integrations are visible, not hidden behind vague automation.
Access controls and operator safeguards
Public access is protected through access codes and login.
Role-based access control supports owner, operator, and viewer modes.
Rate limits, batching controls, and operational safeguards exist to reduce misuse and runaway automation.
Ready to keep going?
Trust should feed the product path, not stop it.
Once the security, privacy, and legal basics feel clear, the next step should be obvious: watch the walkthrough or request launch access.
Next step