Trust and data handling
What Buglyst does with your code and your candidates.
A plain account for engineering leaders and security reviewers. Buglyst Hiring is in beta and run by a small team; this page says what is true today, including what is not in place yet.
Last updated 2026-09-28
Security certifications
Buglyst does not currently claim SOC 2, ISO 27001, or another external security certification. If your procurement process needs a questionnaire answered, talk to Buglyst.
Who operates Buglyst
Buglyst is owned and operated by HARSH SRIVASTAVA as the legal operator (see the Terms). Contracts, invoices, and data-processing questions are handled by the operator directly.
Hosting and execution
Hosting
The application runs in Docker behind Caddy on an Oracle Cloud Infrastructure virtual machine in the ap-hyderabad-1 (India) region. The database is managed Postgres on Supabase.
Candidate code execution
Checks run in a managed E2B sandbox, separate from the application host, with time and output limits. Only the assessment’s own check commands run; candidates cannot run arbitrary shell commands through the check runner. If the sandbox is not configured, checks fail closed instead of falling back to the application host.
Private checks and reference fixes
Stay on the server. Candidates and reviewers see pass or fail, never the private check source or the reference patch.
Encryption in transit
All traffic to buglyst.com uses HTTPS.
Authentication and access
Employer sign-in
Google or GitHub OAuth. Buglyst does not store passwords.
Roles and tenant isolation
Workspaces use roles such as owner, admin, and reviewer. Every workspace request is authorised on the server against the signer’s active membership in that organization; organization ids sent by a browser are never trusted on their own. Database tables have row-level security enabled and are reachable only through the server’s service role.
Candidate access
Candidates need no account. Invite links are random, expiring, and single-use by default, and only a hash of the link is stored. A candidate link can reach only its own attempt.
Audit trail
Workspace owners and admins can see an audit log of invites, starts, submissions, report views, exports, and plan changes.
Candidate data
Before starting, candidates see who invited them, the time limit, the AI policy, and exactly what is recorded, and must consent. Buglyst records workspace activity (files, searches, check runs, submissions, notes, and assistant requests when AI is allowed). It does not use webcams or microphones, does not infer personality, emotion, or protected characteristics, and does not rank or reject candidates. Hiring decisions stay with the employer.
Retention
| Data | What it includes | How long |
|---|---|---|
| Candidate assessment evidence | Timeline, files opened and changed, check results, a fingerprint hash of the submitted patch, candidate notes, AI-use disclosure, and the report. The candidate’s working copy of the repository is stored on Buglyst infrastructure so checks can run. | Kept for the hiring organization while its workspace exists. Organizations can set a retention preference in Settings; automated deletion on that schedule is not yet in place, so deletion is handled on request. |
| Employer account and workspace data | Organization profile, members and roles, assessments, invites, audit log. | Kept while the workspace exists. Deleted on request by the workspace owner, except records we must keep. |
| Billing records | Order ids, plan, amount, status, and dates. | Kept for reconciliation, tax, refund, and legal requirements, including after a workspace is deleted. |
| Operational logs | IP address, user agent, request path, timestamps, rate-limit and error events. | Kept for security and debugging. Not used for hiring decisions. |
| Product analytics | First-party funnel events (plan ids, page names, counts) and Microsoft Clarity page interactions. | Hiring funnel events never include candidate names, emails, code, notes, or report content. |
Service providers (subprocessors)
These are the providers the production service uses today.
| Provider | Purpose | Data involved |
|---|---|---|
| Oracle Cloud Infrastructure | Application hosting (virtual machine, ap-hyderabad-1, India) | All application traffic and server-side processing |
| Supabase | Managed Postgres database | Accounts, workspaces, assessments, invites, candidate reports, billing records |
| E2B | Managed code-execution sandbox | Candidate workspace files while checks run |
| Cashfree Payments | Payment processing (INR) | Order and payment details; card and bank credentials stay with Cashfree |
| Resend | Transactional email delivery | Recipient email address and message content for invites and notifications |
| Google and GitHub | Sign-in (OAuth) | Name, email, and provider account identifier of people who sign in |
| MiniMax | AI model provider | Assistant questions when AI is allowed; approved requirements or code scope for Beta or pilot generation |
| Microsoft Clarity | Product analytics | Page interactions on buglyst.com |
| Fingerprint | Device signals for abuse prevention | Browser and device signals; optional and fail-open |
| Telegram | Private operator alerts | Event notifications to the Buglyst operator, such as a new workspace or contact request |
DPA, deletion, and contact
Data processing agreement
Buglyst does not publish a standard DPA yet. If you need one, request a DPA and it will be prepared with you.
Deletion requests
Workspace owners and candidates can request deletion at privacy@buglyst.com. Requests are verified and answered within 30 days; some billing and security records may be kept where required.
Reporting a vulnerability
See the security policy or email security@buglyst.com.
This page summarises Buglyst’s practices and does not replace the Privacy Policy or Terms.