Test scope, screenshots, checkpoint findings and tier rationale were supplied by an identified reviewer. Identity is retained internally unless public attribution is explicitly enabled.
Cybersecurity / DevOps infrastructure · South AfricaFull evidence record
Salus Cloud
Salus is a governed cloud deployment and operations platform with AI-assisted infrastructure configuration, deployment health, cost/capacity visibility and source-control integration.
Sandbox Africa checked the submitted evidence and promoted the verified checkpoint record. Any visible adjustment is identified rather than silently rewritten.
The official public tier and technical record below are the verified publication outcome.
Tier 2 — Market-Ready
Keep Tier 2. A genuine self-service product and real integration were directly verified; incomplete formal assurance and unexecuted production provisioning block Tier 3.
Strongest supporting evidence
Self-serve access was achieved and the core AI-assisted configuration loop was exercised firsthand across two independent requests, both showing the AI gathers requirements before acting and requires an explicit confirmation step — a manual button press — before provisioning would occur. A working GitHub integration was independently verified via GitHub's own settings page, showing real, functioning write-level access scoped to exactly one repository rather than all repositories — the correct, minimal-exposure configuration. Basic security hygiene was confirmed directly, with a valid, correctly configured TLS certificate. A dedicated "Talk to Security" contact point is present in the product interface, and the company publishes a transparent, dated compliance disclosure rather than an unverifiable claim or silence. Together, all seven checkpoints returned at least a Pass or Partial result, with no checkpoint returning a Fail.
Why the next tier is not yet supported
Tier 3 requires demonstrated, complete compliance and security readiness suitable for corporate procurement — published certifications, formal audit documentation, enterprise-grade compliance evidence. This is explicitly not yet the case here: the company itself states that SOC 2 Type II and ISO 27001 are in progress, not complete, with certification expected in August 2026, and that independent penetration testing results exist but are held under NDA and were not reviewed. The presence of a named security contact channel and a transparent, dated compliance roadmap are supporting signals of a security-conscious posture and a credible path toward Tier 3, but signals of intent and trajectory are not the same as completed evidence, and Tier 3 requires the latter.
Verified findings and limitations
Direct review observations
The intern created a free workspace, exercised Salus Intelligence across two configuration requests and reached an explicit database-creation confirmation step. A GitHub App integration was connected and independently verified from GitHub settings.
Independent verification
The current enterprise site describes governed deployment into customer-controlled cloud environments. It states SOC 2 and ISO 27001 audits are completing in 2026 rather than representing them as already complete.
Observed issues
No material defect was observed in the tested planning/integration flow; formal assurance remains incomplete.
Testing limitations
The database was not actually provisioned, and completed SOC 2/ISO certification or penetration-test evidence was not reviewed.
What was actually assessed
Registered self-serve, reaching a working workspace ("Faithholdings") on the Free plan with a pre-provisioned Production environment and $10.00 in complimentary credits. Reviewed the Deployment Health and Capacity & Cost dashboards, confirming the workspace was live but contained no existing deployments. Opened Salus Intelligence and tested the AI assistant with two separate requests in sequence: first asking it to create a health detection, then asking for help planning a database deployment, recording the AI's clarifying questions and structured guidance in each case rather than assuming automatic action. Continued the database deployment conversation through to its confirmation screen, recording which fields required manual input (username, database name) versus which were pre-selected by the system (instance size, password generation), and noting the explicit "Create Database" button gate. Did not complete the deployment, to avoid consuming trial credits or creating unnecessary live infrastructure for testing purposes. Connected a GitHub account via the Salus GitHub App, then independently verified the resulting access grant through GitHub's own Installed GitHub Apps settings page, rather than relying on the platform's own description of the integration. Located a "Talk to Security" contact button in the product interface and recorded its presence. Reviewed the platform's published compliance status page, recording the stated progress on SOC 2 Type II, ISO 27001 and independent penetration testing. Checked the site's TLS certificate directly via browser inspection to confirm HTTPS configuration.
Environment / device / browser
Edge on Windows
Account or access type
Personal
Access limitations
The database deployment was not carried through to completion, to avoid consuming trial credits or creating live infrastructure solely for testing purposes; the confirmation step's existence was verified, but the resulting deployed resource was not inspected. Integration readiness (Checkpoint 6) and Security basics (Checkpoint 7) were not assessed within the available testing window. Company headquarters were not independently re-confirmed against the live product directly — this profile relies on prior desk research, which itself showed a positioning discrepancy against the live product (see Section 2).
What was observed
These images formed part of the evidence pack considered during verification. Full-standard records retain the contributor's factual caption for each screenshot.
Evidence 1
Deployment Health dashboard Deployment Health overview showing zero activity across all metrics — 0 deployments, 0% successful updates, 100% uptime with nothing running, and "All clear — nothing needs attention" — confirming the trial workspace contained no existing deployments at the time of testing.
Evidence 2
Capacity & Cost dashboard Capacity & Cost screen showing a $10.00 complimentary credit balance (granted 3 days prior) and zero running copies or scaling activity, confirming a funded but unused free-tier account.
Evidence 3
Workspace and environment structure Workspace view for "Faithholdings" (Free plan), showing 0 projects and 1 pre-provisioned environment named "Production," confirming successful self-serve registration reaching a working account structure.
Evidence 4
Salus Intelligence AI assistant AI assistant response to the request "please help me create a health detection," showing four specific clarifying questions (resource monitored, check type, failure trigger, check frequency) rather than automatic action — first evidence toward the human-in-the-loop finding for this platform. If you sent different or additional screenshots that I'm missing, resend them and I'll caption those specifically.
Seven checkpoint assessment
The verified result is the official public checkpoint record. For earlier-standard reviews, these findings may have been reconstructed from preserved evidence during Sandbox Africa’s 2026 audit; they are not presented as if the contributor originally completed a structured worksheet. Contributor-submitted checkpoint wording is shown only where explicit public reviewer attribution has been enabled.
Step 1 — The Existence & Accessibility Check
Is it live?
Checking for dead links, infinite loading screens, or "Coming Soon" landing pages masquerading as live products.
Sandbox verifiedpass
Full authenticated workspace loads correctly, including Deployment Health, Capacity & Cost, and Salus Intelligence assistant panels.
Onboarding friction
Can a user or enterprise actually sign up, or is it gated behind broken "Contact Sales" forms?
Sandbox verifiedpass
Self-serve registration completed independently, reaching a working workspace (“Faithholdings,” Free plan) with $10.00 in complimentary credits and a pre-provisioned Production environment. No sales contact required.
Step 2 — Functional Testing (The "Try It Out" Phase)
Core loop execution
Does the application actually do what it claims to do? (e.g. a payment gateway completing a test transaction, a logistics app's routing engine working.)
Sandbox verifiedpass
The AI assistant function was tested twice with two different requests. Asked to create a health detection, it responded with four specific clarifying questions (resource monitored, check type, failure trigger, check frequency) rather than acting automatically. Asked for help with database deployment, it returned a structured five-point planning framework (database type, workload, deployment model, network/security, monitoring/backups), then continued the conversation into a structured confirmation form requiring explicit user input — username and database name — and a manual “Create Database” button press before provisioning would occur. Several parameters were pre-selected by the system without user input, including instance size (2X-Large, 8 vCPU / 32 GiB / 250 GB, $0.0273/hour) and password generation, which is fully automated post-creation. This confirms a partial human-in-the-loop model: an explicit final confirmation step exists before deployment, but not every parameter requires active user choice. The deployment was not completed, in order to avoid consuming trial credits or creating unnecessary live infrastructure for testing purposes.
User experience (UX) & interface (UI)
Assessing the logical flow, responsiveness, and basic accessibility of the platform.
Sandbox verifiedpass
Clean, well-organised dashboard layout across Overview, Reliability, Capacity and Live Feed tabs. The AI assistant interface is clear and conversational. No rendering faults observed.
Step 3 — Technical & Architectural Assessment
Performance
Load speeds, uptime reliability, and basic stress responses.
Sandbox verifiedpartial
No deployments existed in the trial workspace at any point during testing, so load behaviour, uptime under real activity, and stress response could not be measured. The Deployment Health and Capacity & Cost dashboards displayed only zero-state metrics throughout — 0 deployments, 0 running copies, 100% uptime with nothing running to measure against. The database deployment that would have generated a testable, running resource was not completed, in order to avoid consuming trial credits or creating unnecessary live infrastructure for testing purposes. This checkpoint therefore remains genuinely unassessed rather than assumed to pass or fail. Editorial proposal adjusted from not_assessed to partial using current independent verification and the established gated-product/safety-critical rules.
Verification adjustmentIntegration readiness
Availability, clarity, and functionality of API documentation and webhooks.
Sandbox verifiedpass
GitHub integration was tested directly by connecting a GitHub account via the Salus GitHub App (not OAuth). Verified via GitHub's own Installed GitHub Apps settings page. Permissions granted: read access to administration, checks, commit statuses, metadata and repository projects; read and write access to code, pull requests and repository hooks. Repository access is scoped to "Only select repositories," with exactly 1 repository selected, rather than "All repositories." This confirms genuine, functioning integration capability with a real permissions model, using GitHub's more granular App-based access system rather than broader OAuth scopes. The write-level access to code and pull requests is consequential and should be disclosed clearly to any prospective user, but the narrow repository scope (one repo, not all) meaningfully limits the blast radius of that access.
Security basics
SSL certification, basic encryption standards, and data handling transparency.
Sandbox verifiedpass
HTTPS confirmed via a valid, currently active TLS certificate for salus.cloud, issued by Google Trust Services on 1 July 2026, expiring 29 September 2026 — standard, correctly configured, domain-validated certificate. Combined with the GitHub App integration using scoped, granular permissions (Checkpoint 6) rather than broad OAuth access, this platform shows a consistently more security-conscious posture than most platforms assessed in this stream.
Company right of reply
Claim company profile
Represent Salus Cloud?
Claiming verifies company ownership and enables a response or additional evidence. It does not permit editing of the independent review.