Platform Release Notes
Customer-visible changes to the slim.io platform — Customer Dashboard, scanning behavior, and BYOC / in-customer-cloud deployment options. Scanner agent releases are tracked separately in Scanner Releases.
Platform changes deploy continuously. The dates below mark when each change reached production. No customer action is required for any of these — they take effect on your next scan.
April 2026
Hosting Topology — pick where the scanner runs (and where data is read)
The platform now exposes a two-axis hosting model so each connector can be configured independently:
| Topology | Scanner runs in | Bytes read by |
|---|---|---|
| Slim-Hosted | slim.io infrastructure | slim.io workers (cross-account access) |
| In-Customer-Cloud Agentless | Your cloud account, slim.io managed | A scanner deployed inside your cloud — bytes never leave your tenancy |
| BYOC (Bring Your Own Cloud) | Your cloud account, you manage | Your scanner deployment |
| Hybrid | Mix of the above per connector | Per-connector |
When a connector is created, the wizard adapts to the topologies allowed for your account — if only one is allowed, the wizard skips the picker; if multiple are allowed, you choose per connector. The chosen topology is immutable for that connector to keep audit trails clean. See Scanner Fleet for details.
In-Customer-Cloud Agentless onboarding
For environments that prohibit external data transfer, slim.io can now deploy and manage a scanner inside your AWS, GCP, or Azure account. You apply a Terraform module we provide, the scanner registers automatically with our control plane, and bytes never leave your tenancy. An air-gapped paste-form fallback is available for environments where outbound automation is restricted. See In-Customer-Cloud Agentless in the BYOC guide.
Real-time scan dispatch (BYOC)
BYOC scanners now receive scan tasks over a long-lived connection rather than polling. New scans dispatch in seconds instead of waiting for the next poll cycle. If the connection drops (transient network blip, platform maintenance), the scanner reconnects automatically with backoff and resumes work. Duplicate-task delivery during a reconnect window is filtered on the scanner side, so the same task never executes twice.
Available on the v0.4.0 scanner image and later. v0.3.0 scanners continue to work via the legacy poll path with no behavior change.
Speculative re-execution for stalled tasks
The platform now detects when a scan task’s per-resource throughput falls dramatically below its own startup rate and automatically dispatches a speculative twin on a different worker. The first task to complete wins; the loser exits cleanly without duplicating findings. Idempotent finding writes ensure no duplicates regardless of which twin completes. This shaves the long tail off scans where one worker hits a slow resource (cold storage class, network jitter, oversized object).
Graceful drain during platform updates
When slim.io rolls out platform updates, BYOC and in-customer-cloud scanners receive a clean reconnect signal with random jitter (1–5 seconds) so the fleet doesn’t all reconnect at the same instant. Active scans continue uninterrupted; scanners reconnect on the new revision and resume.
Adaptive backpressure on connectors
When a connector’s downstream system signals it’s under load (HTTP 429 rate limits, 503 Service Unavailable, provider-specific throttle headers), the scanner now slows itself down on a per-connector basis rather than applying a global cap. Throughput recovers automatically as soon as the downstream system recovers. Configured per the published rate limits of each provider — re-verified every six months.
Connector self-healing
Transient errors from cloud provider APIs (HTTP 429, 503, 5xx) are now handled by an automatic retry layer with exponential backoff and jittered sleeps, sized to vendor-documented rate limit windows. Calls that succeed on retry produce a single audit event with the attempt count, not one event per attempt. No code change required on your side — this is on by default for all connectors.
Decision audit trail
Every decision the platform makes during a scan (resource included, skipped, budget exceeded, coverage target met, circuit isolation triggered, resource truncated) is now recorded in an immutable audit trail accessible from the Scan Detail page or exportable for compliance reporting. See Audit Logging for the schema.
Scan profiles renamed for clarity
The three scan profiles previously called Light / Standard / Deep are now Quick / Thorough / Exhaustive across the entire UI. Behavior is identical — only the labels changed. The setting still controls how much load the scanner places on your infrastructure, not slim.io’s.
Schedule and Resource Scope Filter
The Run-Scan modal now exposes:
- Schedule — Run once / hourly / daily / weekly / monthly with timezone-aware start time, instead of CLI-only scheduling.
- Resource Scope Filter — Restrict a scan to specific paths or prefixes within the connector scope without creating a separate connector.
Cost-estimate response simplified
The /api/v1/scans/estimate-cost response no longer returns dollar amounts to customers. Instead it returns runtime in minutes and an estimated coverage percentage — values that are actionable for scan planning. Internal cost estimation for slim.io operators is available via a separate admin endpoint.
Platform reliability improvements
Several invisible safety nets shipped in April. Each is on by default with no customer-facing knob:
- Runaway scan protection — A scan that’s making no progress for an extended observation window pauses, then aborts with a clean Partial outcome rather than burning resources indefinitely. Findings collected up to that point are preserved.
- Per-resource coverage truth — The scan completeness score is computed from actual per-resource outcomes (scanned / skipped / failed / cancelled), not estimates.
- Long-running task baseline persistence — For multi-hour scans, slim.io tracks a per-task throughput baseline on durable storage so a platform restart doesn’t reset stall detection.
TLS 1.3 minimum on all inbound endpoints
All inbound slim.io endpoints (api.slim.io, app.slim.io, dash.slim.io, etc.) now require TLS 1.3 minimum. TLS 1.2 connections are refused at the load balancer.
Earlier changes
For changes prior to April 2026, see the Scanner Releases page (which has historically tracked both scanner-agent and platform changes) or contact your customer success representative.