Trust Center
Security, compliance and transparency at Joy — how the platform, the network and the people who run them protect your data.
Our approach
Joy runs its own network, its own hardware and its own automation, which means security is not a feature we bolt on but the condition for everything else working. This page describes the controls in place today in enough detail to be useful to a security reviewer. If you need something more formal — a questionnaire, a data-processing agreement, an architecture walkthrough — open a ticket to Sales and we will arrange it.
Platform security
- Authentication: Argon2id password hashing; TOTP two-factor authentication with recovery codes; login rate limiting; new-device alerts by email.
- Sessions: bound to device and network characteristics, rotated automatically, revocable from Account → Security. Public pages for anonymous visitors are cached and never contain session data.
- Application: strict Content-Security-Policy with per-request nonces (no inline handlers), CSRF tokens on every form, prepared statements for all database access, output escaping by default, and rate limiting on authentication, contact forms and the API.
- Secrets: hypervisor credentials and VM passwords are encrypted at rest with XChaCha20-Poly1305 under a key held only by the core; API tokens are stored as SHA-256 hashes and shown once.
- Audit: every staff and customer action on an account is written to an audit trail visible to the customer, including reads of credentials.
- Dependencies: the platform is dependency-free PHP with no third-party front-end assets; nothing loads from external CDNs.
Infrastructure security
- Isolation: customer VMs are KVM-isolated on the Compute Fabric; customer networks are VLAN-segmented; hypervisor APIs live on private networks reachable only from the regional collector.
- Cluster: a core, an edge tier and regional collectors communicate over HMAC-signed requests with per-node tokens that can be revoked individually; bootstrap tokens are single-use.
- Network: always-on DDoS scrubbing on AS152565; RPKI ROAs for every prefix and RPKI-invalid routes dropped; uRPF on customer ports; NeuroMesh NetFlow telemetry encrypted end to end.
- Facilities: Tier III datacenters with badge and biometric access, CCTV, redundant power and cooling; hardware is owned by Joy and decommissioned drives are wiped or destroyed.
- Backups: platform databases are backed up hourly and replicated to a second region; customer data backups are a customer-controlled product.
Payments
PCI DSS scope is delegated to Razorpay, PayPal, a hosted card checkout and BTCPay. Joy never sees, transmits or stores full card numbers; we receive transaction references and the last four digits for display. Webhooks from payment providers are signature-verified before any invoice is marked paid.
Data handling
We do not access the contents of customer servers except for support at the customer's request, to investigate a suspected Terms violation, or where legally required. Personal data is processed as described in the Privacy policy, stored in India with encrypted backups in Singapore, and deleted on the schedule published there. Data-processing agreements are available for enterprise customers.
Legal requests and transparency
We disclose customer data to authorities only on receipt of a valid legal request under the laws of the country where the data is held, and we notify affected customers unless prohibited. We publish counts of requests received and complied with in our annual transparency note in the Updates feed.
Responsible disclosure
Report vulnerabilities to security@joy.services. Please include steps to reproduce and do not access other customers' data. We acknowledge within 48 hours, keep you updated, fix confirmed issues promptly and credit researchers publicly (with permission) and with wallet credit. We do not pursue legal action against good-faith research that follows this process.
In scope
joy.services and subdomains, the console and API, 1tbShare, and the network services of AS152565.
Out of scope
Denial-of-service testing, social engineering of staff, physical attacks, third-party services we use (report those to their owners), and findings that require a compromised customer device.
Business continuity
The platform runs across a core and multiple edge nodes; the core database is replicated and can be restored in a second region within hours. Compute regions are independent: a failure in one does not affect servers in another. Incident response follows a documented run-book with public updates on the status page and a post-incident report in the Updates feed for anything affecting customers for more than 30 minutes.
Compliance roadmap
We are working towards formal certification of the controls above; until then this page, the Privacy policy and our answers to your questionnaire are the reference. Ask Sales for the current status.