Skip to content
CodderBulgarian Legion

Legal

Privacy Policy

Last updated: Pending publication

What Codder collects, why it is needed, how long it is kept and how to remove it. The technical descriptions below reflect how the software actually behaves.

Requires business and legal input

The data controller identity, contact address, Data Protection Officer (if required), lawful bases per processing activity, international transfer mechanism and supervisory authority must be supplied before publication.

What we store

Account data

Username, display name, email address, a password hash (Argon2id — never the password itself), optional country, interface language, and account timestamps. Needed to operate your account and sign you in.

Conversations and content

Your messages, Codder responses, uploaded files, projects and project settings. Stored so your work persists between sessions. Uploaded files are written outside any web-served directory and are readable only through an authenticated request that re-checks ownership.

Memories

Short durable facts about how you work — target core, branch, operating system, compiler, database, coding conventions. Extracted only from your own messages, and only when they pass a filter that rejects credential-shaped content. Never taken from uploaded files. You can view, edit, delete or disable memory entirely on the Memory page.

Usage and technical data

Message counts, token counts, generation durations, error codes, plan and subscription state, and — for security — the IP address and browser user agent attached to each session, plus counters used for rate limiting and lockout.

Payments

If you subscribe, we store the payment provider identifiers, amounts, currency and status. We never see or store your card details; those go directly to the payment provider.

What we do not do

  • We do not sell your data.
  • We do not use your conversations to train models.
  • We do not log the content of your messages. Application logs contain identifiers, counts and durations only, with credentials redacted at the logger.
  • Administrators can see usage counts and account metadata, not your conversations.

Where your content goes

To produce a response, the relevant parts of your conversation — recent messages, selected memories, project context and any files you attached — are sent to the inference service configured for this deployment. Where that service runs, and under whose control, depends on the deployment.

Requires business and legal input

Name the inference provider(s) actually used in production, the hosting region, and whether inference is self-hosted by Bulgarian Legion or provided by a third party. If a third party is used, its role as processor and any transfer safeguards must be disclosed here.

Retention

  • Conversations, projects, files and memories: until you delete them or delete your account.
  • Sessions: until they expire or you revoke them; expired rows are purged by a scheduled job.
  • Verification and reset tokens: purged once used or expired.
  • Usage records: retained for capacity planning and abuse investigation.
  • Billing records: retained as long as accounting rules require, in anonymised form after account deletion.

Requires business and legal input

Concrete retention periods (in months or years) for usage records and billing data must be set according to the operating jurisdiction.

Your rights

Depending on where you live you may have rights of access, rectification, erasure, restriction, objection and portability. In practice, most are exercisable directly in the product: profile fields are editable, conversations, projects, files and memories are individually deletable, memory can be switched off, and account deletion removes your conversational content and anonymises your record.

Cookies

Codder sets one essential cookie: your session. It is httpOnly, Secure in production and SameSite=Lax. There are no advertising or third-party tracking cookies. See the Cookie Policy.

Security

Argon2id password hashing; session tokens stored only as hashes; encryption at rest for stored provider credentials; ownership enforced inside every database query; rate limiting and account lockout on authentication; strict validation on uploads, which are never executed. Full detail is in the project SECURITY document.

Contact

Privacy questions and requests: see the contact page.