Information Security Policy
This is how Opensolr protects the two things you trust us with: your account, and the data inside your indexes. It covers what we hold, where it lives, who can reach it and what keeps it that way. We review it every quarter and update it as the platform changes.
The five gates, in the order a request meets them.
Opensolr is certified for information security management and for quality management. Both are audited standards, not self-declared ones. About our certifications
We re-run our internal security review every quarter, patch what it finds across the fleet and refresh the published security overview with the results.
Our controls are mapped to the five SOC 2 Trust Services Criteria and to the SIG and CAIQ questionnaires. A PDF security overview, completed questionnaires, a data processing agreement and an architecture overview are available on request. Open the Trust Center
Two kinds of data, two homes. You decide where the second one lives.
Your email address and password, your API keys and the log of what was done in your account. That is all an account is. Payment details never touch our servers: billing runs through Stripe, which is PCI compliant. Account data is stored on Opensolr servers and is visible only to you, the account owner, in the control panel.
The documents you index, the configuration files of the index and the log of requests made to it. You pick the server and region when you create an index, from datacenters run by AWS, Hetzner, HostHatch and Alibaba Cloud in North America, Europe, Asia and Australia. The data stays where you put it.
There are two doors, the account and the index, and each has its own locks. The account door leads to the control panel. The index door leads to the data, and every request has to unlock it.
A password, and optionally a second factor delivered to your phone through Authy or SMS. reCAPTCHA protects the login, registration and password reset forms, and every new registration is screened before a verification code is sent. Enable two-factor authentication
Invite colleagues, developers or contractors with their own login. You choose which indexes each person sees and which actions they may perform. Billing, API keys and team administration always stay with the owner, and removing a member revokes everything at once. Teams management
Every index requires a username and password on every request, on every handler. A new index starts with the username opensolr and your master API key as the password. Change both in the Security tab of the index; the new credentials are live within about ten seconds. HTTP authentication guide
Allow specific addresses on specific handlers: let the world search, but let only your own server write. Valid credentials from an address that is not on the list are still refused. An index with no rules at all is invisible to everyone. IP rules explained
Indexes that come with a ready-made search page can require a login before anyone searches. Switch it on in the Security tab; it uses the same credentials as the index itself.
Cross-origin requests from a browser straight to an index are refused unless your domains have been whitelisted. Ask us and we add exactly the origins you name. CORS and origin whitelisting
The master key opens everything. A scoped key opens only what it was granted, on the indexes it was granted, for as long as you decide.
Every account has one master key. It can call every endpoint of the API on every index, and it is also the initial HTTP password of each new index. Keep it with the owner, never in client-side code or a shared repository, and regenerate it from the dashboard if it may have leaked.
Create as many additional keys as you need under Account › API Keys. Each one is limited to the endpoints you tick and, if you want, to a named subset of your indexes. Anything else returns a 403. A key can carry an expiry date, can be revoked or regenerated on its own without touching any other key, and records when it was last used. Only the account owner can manage keys. Master key versus scoped keys
Rate limits per account and per address, with a proper 429 when they are exceeded, and monthly quotas are counted against your account whichever key made the request. A leaked scoped key cannot spend more than the account it belongs to.
- Index data is written only through requests that authenticate against the index and pass its IP rules: by you, by a team member you gave write permission, or by a key you granted write access.
- Configuration changes are validated before they apply. An invalid schema or configuration file is rejected and the live index keeps running on the previous one. There is no half-applied state.
- Account data is changed only by you in the control panel, or by our staff on your explicit written request. Every change is logged with who made it and when.
Writes go to the master, reads spread across replicas, snapshots come from the master, and a watchdog restarts whatever fails.
Take a snapshot of an index whenever you want, or switch on daily backups and get one every night. Download any backup to your own storage, and restore either the whole index or only its configuration. Backups are kept for seven days. Backup and restore
An index can be replicated to servers in other datacenters. Replicas serve reads, survive the loss of the master and bring the data closer to your users. Index replication
Every server in the fleet is checked every five seconds. A service that stops answering is restarted automatically, and the state of every server is published on the service status page. We run to a 99.9% uptime target.
Every Solr server enforces per-address request-rate and connection limits in the kernel firewall, so a flood is discarded before it can occupy a worker. Addresses that scan or attack are banned automatically, and public search pages challenge bots before they can query anything.
Abusive query patterns against your index trigger an alert to you and your team. A weekly digest summarises the errors your index produced, so a broken integration is noticed before your users notice it. Weekly error digest
The Opensolr account database is dumped every hour to a separate backup server, so the platform itself can be rebuilt from a copy that does not share the fate of the primary.
The website, the API and every hosted index accept TLS 1.2 and 1.3 only; older protocols are refused. HTTP is redirected to HTTPS and a two-year HSTS policy with preload keeps browsers there. Certificates are renewed automatically before they expire, so an expired certificate cannot take a customer down.
A new account is created only after the address behind it passes six checks, in order: a bot challenge, a country policy, a domain reputation service, a list of disposable providers, the DNS health and age of the domain, and finally a code sent to the address itself. Why an address can be rejected
The six layers of registration screening, cheapest first.
Opening an account takes an email address and a password. We never ask for biometric data, and a phone number is stored only if you choose to turn on two-factor authentication.
- Solr is never public. Every Solr instance listens on localhost only. The single way in is the authenticated HTTPS front on the same server.
- Dangerous Solr features are off. The data import handler is disabled fleet-wide, configuration editing and core administration endpoints are blocked at the edge, and remote streaming is disabled. Data import handler
- Known vulnerabilities are mitigated across the fleet, whichever Solr version an index runs on. Log4j, for example
- Default-deny firewalls on every server. Databases are not reachable from the internet, and administrative SSH to the Solr servers is accepted only from our management host, with keys, never passwords.
- The application is hardened too. A Content Security Policy and a full set of security headers are applied centrally, database access is parameterized, state-changing requests carry a CSRF token, and every input is validated for the exact place it ends up in.
Logins, changes to indexes and changes to settings are recorded with the time and the account that made them, and shown to the owner in the control panel.
The request log of each index is yours to read: analytics and charts in the control panel, a live tail of the last requests, and the same log through the API, so you can see exactly who queried what and when. Monitoring and analytics
Each scoped key shows when it was last used, and the account keeps a request counter, so a key that should be idle and is not stands out immediately.
Changes we make on your behalf happen only after a written request from you, and the request and what was done stay on record.
We collect the minimum an account needs and nothing more. We do not sell, trade or share personal information, and you can ask for your account and its data to be erased at any time. The full terms are in our GDPR privacy agreement and our privacy policy. A data processing agreement is available on request.
These are the third parties that help us deliver the service, and what each one handles.
| Provider | Purpose | Data handled |
|---|---|---|
| AWS, Hetzner, HostHatch, Alibaba Cloud | Datacenters for hosted indexes, by region | Your index data, in the region you chose |
| Stripe | Payments and billing | Payment details, never stored by Opensolr |
| Twilio / Authy | Two-factor authentication delivery | Phone number, only if you enable it |
If you believe you have found a security issue in Opensolr, write to support@opensolr.com or use the contact form. We respond promptly, we do not pursue good-faith researchers, and we say thank you. The same addresses work for questions about this policy, for questionnaire requests and for a data processing agreement.
The detail behind this page
The Trust Center maps every control above to the SOC 2 criteria and the SIG and CAIQ questionnaires, with a downloadable PDF.
Open the Trust CenterMaster key versus scoped keys- Solr Cloud data security: IP rules, HTTP authentication and TLS, in one page.
- Default HTTP authentication credentials of a new index, and what regenerating the API key does and does not change.
- Platform security guide: the Security tab of an index, step by step.
- ISO 27001 and ISO 9001 certification.
- GDPR privacy agreement, privacy policy and terms and conditions.
This policy evolves with the platform and with the industry. If you think something is missing, tell us.
