Where your code goes, in four lines
Stepclimb runs your upgrade in a sandbox that exists for one run. This page says what that means, what we keep and who else is involved.
- Line 1
One sandbox per run
Each run gets its own sandbox with no host mounts. It is destroyed when the run ends.
- Line 2
Network allow list
The sandbox can reach package registries and GitHub, nothing else. Blocked hosts are logged.
- Line 3
Tokens stay outside
Installation tokens are scoped to one repo and expire within an hour. The sandbox never holds them.
- Line 4
No retained code
We do not retain customer code. Logs are kept 30 days with secrets redacted.
What a free inspection reads
The free inspection reads composer.json, composer.lock and package.json only (plus the list of file names, to find each app), through the GitHub App you install on the repositories you choose. No code is cloned. The report shows versions behind, the support end date, the recipes that apply and an effort band from S to XL.
What an upgrade run does
- The repo is cloned into a fresh sandbox. Recipes apply as one commit each, then composer install, your asset build and your tests run.
- If something breaks, repair rules match known failures and re run up to three times. Nothing is sent to an AI service.
- A run stops at 25 minutes. The sandbox is destroyed in every case, success or failure.
- The pull request, its comments and the Verified check are created by our servers, outside the sandbox. We never merge.
Account and application security
- Sign in uses GitHub, with optional two factor authentication. The free tier needs a GitHub account at least 30 days old.
- API keys are shown once and stored hashed. Outbound webhooks are signed so you can verify them.
- Incoming webhooks from GitHub and Stripe are signature checked.
- Rate limits protect public endpoints and the API.
Sub processors
In the first release we run on shared infrastructure providers, so the list is longer than one entry. It is the same list as on the sub processor page, and it comes from our product configuration.
| Provider | Purpose | Location |
|---|---|---|
| Vercel Inc. | Hosting, edge network and the sandboxes that run upgrades | United States |
| MongoDB Inc. (Atlas) | Database hosting | United States (AWS us-east-1) |
| Cloudflare Inc. | DNS, scheduled jobs and file storage | United States |
| Stripe Inc. | Payments and invoicing | United States |
| Email delivery provider | Transactional email until our own mail servers are live | United States |
Report a vulnerability
Email contact@buffersoltech.com with the details and steps to reproduce. Please give us reasonable time to fix the issue before you disclose it. We will not take legal action against honest research. More on the security policy and the data processing addendum.
Common questions
Do you clone my private code?
Only when you ask for an upgrade run. The code goes into an isolated sandbox that is destroyed when the run ends, and we do not retain it. A free inspection does not clone anything: it reads composer.json, composer.lock and package.json only.
Does any AI service see my code?
No. Recipes and repair rules make the changes, and nothing is sent to an AI service. The prompts we attach to squawks are templates for your own agent.
Can Stepclimb merge into my main branch?
No. Stepclimb opens a pull request and never merges. Merging stays with you.
Do you have SOC 2 or ISO 27001 certification?
No. We do not claim any certification. This page lists what we do, and nothing we do not do.
Who are your sub processors?
The table on this page lists them. In the first release Vercel, MongoDB Atlas and Cloudflare are infrastructure sub processors, alongside Stripe for payments and an email delivery provider. We will give 14 days notice before adding or replacing one.
Start with a report that clones nothing
The free inspection reads composer.json, composer.lock and package.json only. No code is cloned.
Free inspection first. Cancel at period end. Pause up to 3 months.