What Happens When DartUp Scans Your Code
DartUp lets anyone deploy code to a shared server. That's a security problem if you don't handle it carefully. Here's how we make sure user code can't do anything it shouldn't.
Why We Scan
When you deploy to DartUp, you're uploading code that runs on our servers. Most people deploy legitimate apps. But the internet being what it is, we have to assume some deployments won't be friendly.
Cryptominers. Reverse shells. SSRF attacks against cloud metadata endpoints. Attempts to escape the container and access the host system. These aren't theoretical risks. They're things that actually happen on shared hosting platforms.
So every deployment goes through a security scan before the code ever runs. If something looks wrong, the deployment gets blocked. No exceptions.
What the Scanner Checks
The scanner looks at your source files before the build step. It checks for patterns that indicate malicious intent or dangerous misconfiguration:
Docker Socket Access
Code that tries to mount or connect to /var/run/docker.sock. This is the classic container escape vector. If your code can talk to the Docker daemon, it can create privileged containers, mount the host filesystem, and take over the server. We block this completely.
Host Filesystem Escapes
Path traversal patterns, bind mounts to host directories, attempts to read/etc/shadow,/proc, or other host system files. Even inside a container, there are ways to poke at the host if the container isn't locked down. The scanner catches the common ones.
Reverse Shells
Netcat, bash TCP redirections, Python socket connections back to external IPs. These are the standard toolkit for turning a compromised server into a backdoor. The scanner recognizes the common patterns across multiple languages.
Cryptominers
XMRig, CGMiner, references to mining pools, Stratum protocol connections. Free compute is attractive to miners. We'd rather they find a different hobby.
SSRF Patterns
Requests to cloud metadata endpoints like 169.254.169.254. On cloud servers, this endpoint can leak IAM credentials, API tokens, and infrastructure details. The scanner blocks hardcoded metadata access.
Credential Harvesting
Code that reads AWS credentials, Stripe keys, or other secrets from well-known paths. If someone's trying to access ~/.aws/credentials or environment variables they shouldn't have access to, the scanner flags it.
Privilege Escalation
Dockerfile instructions that try to run as root, add capabilities, or disable security profiles. All DartUp containers run as a non-root user (uid 1001) with a restrictive seccomp profile. The scanner catches attempts to override this.
What Happens When Something Gets Flagged
The deployment stops. You get an error message explaining what was found:
You: Deploy this to DartUp
Scanning project...
✗ Security scan failed
Found: Docker socket access attempt in server.js:42
Pattern: /var/run/docker.sock
Deployment blocked. Remove the flagged code and try again.
Most false positives come from Docker tutorials or boilerplate code that references Docker internals in comments or documentation strings. If you get flagged and it's a false positive, remove the offending pattern (usually a comment or unused code) and redeploy.
Beyond Scanning: Runtime Isolation
Scanning is the first layer. But scanners can miss things, so we don't rely on scanning alone. Your code also runs with multiple runtime restrictions:
- Non-root user: Your container runs as
appuser(uid 1001), not root. This limits what system calls and files are accessible. - Seccomp profile: A whitelist of allowed system calls. Things like
mount,ptrace, andrebootare blocked at the kernel level. - Resource limits: 512MB memory, 0.5 CPU. If your process tries to consume more, the container gets throttled or killed. No single deployment can starve the server.
- Isolated build: Builds run in a separate Docker daemon. Your build process can't access other users' containers or the host Docker socket.
- Network isolation: User containers run on isolated networks. They can reach the internet but not other users' containers or internal services.
How This Compares to Other Platforms
Most hosting platforms rely on container isolation alone. That works until someone finds a container escape. DartUp layers scanning on top of isolation, so even if there's an undiscovered container vulnerability, the most common exploit patterns get caught before the code ever runs.
Is it perfect? No. Security is a spectrum, not a binary. But it's significantly better than running arbitrary code with Docker defaults, which is what many self-hosted platforms do.
What It Means for You
If you're deploying a normal app, you won't notice the scanning. It runs in under a second as part of the build process. Your Flask API, your Express server, your static site, your Next.js app? They all pass without issue.
You'd only hit the scanner if your code contains patterns that look like they're trying to break out of the sandbox. Normal application code doesn't do that.
FAQ
Does DartUp scan my code?
Yes, every deployment goes through a security scan before building. It checks for container escape patterns, reverse shells, cryptominers, SSRF attempts, and credential access. Normal application code passes instantly.
Will the scanner flag my legitimate code?
Rarely. The patterns it looks for are specific to exploitation techniques. If you do get a false positive, it's usually from a comment or documentation string that references Docker internals. Remove the pattern and redeploy.
Can I see what was scanned?
If the scan fails, you get a specific error message showing the file, line number, and pattern that was flagged. If the scan passes, it's transparent — you just see your deployment succeed.
Is my code stored after the build?
Your source code is processed during the build to create a container image. The source files are not stored separately after the build completes. The running container contains the built output.
Deploy with confidence
Security scanning on every deploy. Container isolation by default.