Security Policy
Effective · Version 2026-10-15
How your account, your data and the code you run are protected, the limits that apply to Programs, and how to report a vulnerability.
1. Our commitment
- 1.1
Keeping the data we hold safe is the one responsibility IntelliJ.ONLINE fully accepts. We combine collecting as little as possible with layered technical protection, and we keep improving it.
2. Separate addresses
- 2.1
- 2.1.1
intellij.online and www.intellij.online serve only the public home site and legal pages; they never handle your projects;
- 2.1.2
workspace.intellij.online serves sign-in, your projects, the IDE and Contact Support;
- 2.1.3
gateway.intellij.online serves only the API; it accepts requests that come from the workspace and rejects others;
- 2.1.4
the sign-in cookie is shared only between these addresses.
- 2.1.1
3. Connections
- 3.1
- 3.1.1
all addresses are served only over HTTPS through Cloudflare, which also filters attacks;
- 3.1.2
our servers accept web traffic only from Cloudflare, and the connection between Cloudflare and our servers is encrypted and authenticated with a certificate;
- 3.1.3
on top of HTTPS, every request from the workspace to the API and the collaborative-editing connection are encrypted end to end at the application level with keys agreed for each session, and protected against tampering and replay;
- 3.1.4
pages are sent with headers that prevent framing and content-type sniffing.
- 3.1.1
4. Accounts and sessions
- 4.1
- 4.1.1
passwords are stored only as salted Argon2id hashes;
- 4.1.2
email addresses and nicknames are looked up through keyed hashes;
- 4.1.3
sign-in and registration are rate-limited, and registrations from the same network are spaced out;
- 4.1.4
session tokens are random, stored only as keyed hashes, sent in an HttpOnly, Secure, SameSite=Strict cookie and expire after at most 30 days;
- 4.1.5
we can sign an account out on all devices and block it if it is misused or compromised.
- 4.1.1
5. Data at rest
- 5.1
- 5.1.1
the database holding accounts, projects, files, history, logs, tickets and attachments is encrypted at rest;
- 5.1.2
daily backups are copies of the encrypted database, and only the most recent few are kept;
- 5.1.3
build workspaces are separate for every project, and dependency caches are separate for every account;
- 5.1.4
every request for a project, file, ticket or attachment is checked on the server against its owner;
- 5.1.5
attachments are checked when uploaded, are shown only as image previews or downloads, and are never opened or executed by the Service.
- 5.1.1
6. Isolated execution
- 6.1
Builds and Programs run on our servers inside isolated environments:
- 6.1.1
each run gets its own sandbox with separate processes, a private temporary directory and a read-only view of the system;
- 6.1.2
a Program can read and write only its own project and build cache, and cannot see other users' data or the Service's files and secrets;
- 6.1.3
Programs have no network access; build tools reach only public package repositories — the well-known ones and those named in your build files — through a filtering proxy that blocks the host machine and private networks;
- 6.1.4
servers, open ports and graphical windows are blocked;
- 6.1.5
system calls, JVM options and environment variables that could weaken isolation are filtered, and the Java runtime is started with remote-code and attach features disabled;
- 6.1.6
resource limits are enforced, and blocked actions are recorded.
- 6.1.1
- 6.2 LimitCurrent valueMemory for a ProgramUp to 1 GB (larger -Xmx values are lowered)Memory for Maven and javac builds / Gradle buildsUp to 2 GB / up to 3 GBRun time10 minutes for a Program, 30 minutes under the debugger, 15 minutes for a buildRuns at the same time2 per account, fewer when the server is busyConsole outputUp to 2 MB per processData written by one runUp to 3 GB, and never more than the free storage of the accountNetworkNone for Programs; public package repositories only for build toolsProjects per account200Files per project10,000File size2 MB for text files, 20 MB for other filesStorage8 GB per project, 50 GB per account, including history and build outputSupport attachments3 files per message, 5 MB each
- 6.3
Limits may change and may differ for individual accounts.
7. Administration
- 7.1
Administrative access is limited to the operator's authorised staff, is separated from the public parts of the Service and is recorded. It is used only for the purposes described in the Terms of Service.
- 7.2
We do not scan the content of your projects. Automatic protections act on behaviour — what a Program tries to do — not on what your code says.
8. Your part
- 8.1
- 8.1.1
use a strong password that you do not use anywhere else, and never share it;
- 8.1.2
sign in only at workspace.intellij.online, and never enter your password on a page that only looks like ours;
- 8.1.3
sign out on shared or public devices;
- 8.1.4
do not keep real passwords, private keys, API tokens or other people's personal data in projects, messages or attachments;
- 8.1.5
if you think your account is compromised, sign out and tell us immediately through Contact Support.
- 8.1.1
9. Reporting a vulnerability
- 9.1
If you find a security problem, open a ticket in Contact Support under Bug report and start the subject with "Security". Describe the issue, the steps to reproduce it and its possible impact. Do not share it publicly until we have fixed it.
- 9.2
When you research the Service, you must:
- 9.2.1
test only your own account and projects;
- 9.2.2
stop as soon as you gain access to anything outside them, and not copy, keep, change, use or disclose what you saw;
- 9.2.3
not attack other users, our providers or our infrastructure, and not use social engineering, phishing or denial of service;
- 9.2.4
not degrade the Service for others, for example with load tests or automated scanning.
- 9.2.1
- 9.3
We will not take action against research done in good faith and within these rules, and we will credit reporters who wish it. There is currently no paid bug bounty.
10. Incidents
- 10.1
If we detect a security incident, we contain it, investigate what was affected, restore protection, and notify affected users and authorities where the law requires it.
- 10.2
No system is perfectly secure. We continuously improve our protection, but we cannot guarantee that a breach will never happen.