New Sciple is live. Connect your AWS in 10 minutes and explore the platform with a sandbox workspace. Book a demo
sciple
Built for AWS-native engineering teams

A Platform your Team Needs.
Runs on your Own Infra.

Sciple gives your team a complete service catalog, documentation, project and ticket management, AWS resource browser, Kubernetes and ECS view, CI/CD and jobs runner, secrets and configuration management, security scanning, unified observability, backup tracking, and an AI assistant, all in one platform. Runs serverless in your infrastructure, sharing a single identity model and a single audit trail across every capability.

Book a demo See every feature Meet the AI assistant →
0
Capability surfaces shipped today, all in one product
0
From AWS connect to a fully queryable platform
0
Native integrations across AWS, K8s, SCM, identity, observability

Platform anatomy

Three layers. Fourteen surfaces. One foundation.

Your team works through a single Sciple platform that runs in your AWS infrastructure. Every capability surface, from the service catalog through observability and the AI assistant, inherits the same foundation: audit trail, RBAC, SSO, single identity model, workspace isolation, and an open HTTP API. Visibility, ownership, and compliance are wired in from the first connection rather than stitched together later.

I Your Team Who uses the platform Developers Platform engineers Security Operations Audit Leadership operate · observe · govern II Sciple Platform 01 CATALOG Service catalog Services · owners · health Compliance · tickets · docs 02 DOCS Documentation Wikis · runbooks · RFCs · ADRs Service-anchored · AI-grounded 03 PROJECTS Project & Ticket Management Issues · sprints · SLAs Auto-routing · Jira / Linear sync 04 CLOUD Cloud (AWS) Compute · networking · data IAM · edge · code suite 05 KUBERNETES Container orchestration EKS · ECS · Fargate Live resources · Helm 06 CICD CI / CD & Jobs Pipelines on CodeBuild Cron · ad-hoc on Fargate / EKS 07 CREDENTIALS Secret & Config Management AWS Secrets Mgr · Parameter Store Layered override · rotation · audit 08 BACKUPS Backups & DR RDS · EBS · AWS Backup · S3 repl Failure alerts · RPO · restore tests 09 SECURITY SCANNING Security scanning & ASPM Code · DAST · Infra · Cloud One ASPM queue · owner attached 10 OBSERVABILITY Observability & Incident Mgmt Logs · metrics · traces · incidents Unified dashboard · on-call · status page 11 AI AI assistant Navigator · triage · scorecards Reads platform · cannot read secrets 12 RUNBOOKS Runbooks Notebook cells · shell · HTTP K8s · ECS · EC2 · AI-authored 13 MCP MCP server Claude-callable tools Author in chat, you approve 14 DEV TOOLS Dev Tools SQL Console · RDS in-VPC IAM / basic · SSH · SSM · direct ⊥ FOUNDATION / SHARED ACROSS EVERY SURFACE Audit trail RBAC SSO (OIDC) Workspace isolation Single identity model Open HTTP API Webhooks Workspace-scoped data runs in your infrastructure III AWS Substrate runtime · proxied · workspace-scoped Secrets Manager · Parameter Store · CodeBuild · IAM · ECR · Security Hub · GuardDuty · Inspector · CloudWatch · X-Ray

One platform between your team and your infrastructure.

Platform reference

Fourteen surface areas. One product.

Every capability shipped today, with the depth that used to live on a separate product page. Pick a surface to read the bullet list and the categorised detail underneath it.

Service catalog

A single source of truth for what your team owns.

Every service is a first-class record with the metadata engineers actually look up. The catalog is the anchor for configuration, pipelines, scorecards, the unified observability dashboard, and backup tracking. Nothing about your team’s software lives in a wiki any more.

  1. Service identity in one record. Name, slug, kind, language, runtime, tier, SCM repository, default branch, and tags. The canonical metadata every other module references.
  2. Owners, teams, and on-call. Every service is bound to an owner group and on-call rotation, so paging, approvals, and escalation route to the right humans automatically.
  3. Operational documentation. Architecture docs, runbooks, dashboards, and design references attach to the service and surface alongside it during incidents, reviews, and onboarding.
  4. Configuration with full change history. Configuration attaches to a service, and every revision is recorded against the engineer, PR, and timestamp that introduced it.
  5. CI/CD activity per service. Pipelines are owned by a service-and-environment pair, so build, deploy, and release history is visible per service across every environment.
  6. SCM linkage on every service. Each service is bound to a repository on GitHub, GitLab, Bitbucket, or Azure DevOps. Repository lists are fetched live, branch protection is surfaced, and the URL, default branch, and description come from the SCM rather than being hand-typed.
  7. Observability joined in context. Metrics, logs, and traces from Prometheus, Grafana, Loki, Jaeger, OpenTelemetry, Elasticsearch, OpenSearch, CloudWatch, and X-Ray are stitched to the service across every environment.
  8. Unified dashboards across logs, metrics, and traces. Build a single per-service dashboard that overlays metrics, log streams, and trace spans side-by-side, drawing from your existing telemetry stack. One canvas for the three pillars; no tab-switching during incident triage.
  9. Service health at a glance. Error rate, latency, deployment freshness, scanner findings, and open incidents roll up into a single live health view per service.
  10. Backup tracking and failure alerts. RDS snapshots, EBS snapshots, AWS Backup vault jobs, and S3 replication state are tracked per service. Failed or missing backups are flagged in the catalog and routed to the owning team with a full audit trail of every backup attempt.
  11. Compliance and policy posture. Frameworks, control mappings, and posture findings attach to the service, making the audit story per service one page rather than a spreadsheet.
  12. Tickets and contributor activity. Linked issues, pull requests, recent contributors, and pending work surface against the service, giving leadership a real picture of activity without chasing across tools.
  13. Faster troubleshooting end to end. Ownership, change history, observability, deploy state, and recent activity all join the same record, materially shortening the path from alert to root cause.

Documentation

A native wiki where every page knows which service it belongs to.

Sciple ships a markdown documentation system as a first-class surface. Pages are typed (runbooks, RFCs, ADRs, architecture, onboarding), versioned, owned, and bound to services in the catalog. The AI assistant reads your wiki so on-call gets answers grounded in your own docs. Optional two-way sync with Notion and Confluence.

  1. Markdown documentation as a first-class surface. Sciple ships a full wiki with a markdown editor, live preview, version history, and review workflow. Pages are owned, dated, and bound to one or more services in the catalog.
  2. Typed pages, not a wiki dump. Pages carry a type, such as runbook, RFC, ADR, architecture, onboarding guide, or postmortem, so engineers can filter, list, and link to the right kind of doc instead of grepping a flat tree.
  3. Service-anchored by default. Every doc lists the services it covers. The service catalog auto-links to the most-relevant docs, so on-call lands on the runbook for the right service in one click.
  4. Comments, approvals, and audit trail. Comment threads, approver workflows for RFCs and ADRs, and the full edit history of every page land in the same audit log as the rest of the platform.
  5. AI assistant grounded in your wiki. The assistant indexes your documentation and answers "how do I" questions using your actual runbooks and architecture docs, not generic Stack Overflow snippets.
  6. Optional sync with Notion and Confluence. Keep your external system of record if you have one. Sciple two-way syncs selected spaces or pages, so the catalog still surfaces docs that live elsewhere.
  7. Searchable across services, types, and content. Full-text search filters by page type, owner, service, last-updated, and approval state.

Project & Ticket Management

A native ticket tracker that lives inside the service catalog.

Sciple ships a full ticket tracker. Issues, epics, and sprints attach to the service they affect. Automation creates tickets from incidents, scanner findings, failed backups, and missed RPOs, and routes them to the owning team. Optional two-way sync with Jira, Linear, GitHub Issues, and GitLab Issues.

  1. Issues, epics, and sprints as first-class objects. Sciple ships a full ticket tracker with statuses, severities, assignees, due dates, and SLAs. Sprint planning with capacity per team is built in.
  2. Tickets attach to the service they affect. Every ticket is bound to one or more services in the catalog. No orphan tickets, no "which service does this even belong to" archaeology.
  3. Auto-creation from platform events. Scanner findings, failed pipelines, failed backups, missed RPOs, drift detection, and incidents can all open tickets automatically, routed to the owning team through the service catalog.
  4. SLA enforcement and escalation. Severity and tier drive SLA timers. Approaching breaches escalate up the on-call chain. Breach reports roll up per team and per service.
  5. Two-way sync with external trackers. Optional bi-directional sync with Jira, Linear, GitHub Issues, and GitLab Issues if you want to keep an existing tracker as the source of truth.
  6. AI-assisted triage. The AI assistant groups related tickets, suggests assignees based on service ownership and recent activity, and proposes severity downgrades or duplicate links.
  7. Audit trail on every transition. Every status change, assignment, comment, and SLA event is recorded with the engineer and timestamp, in the same log as the rest of the platform.

Cloud (AWS)

AWS resource details at your fingertips.

Connect an AWS account once and every resource detail your team needs is a search away. Ownership, cost signals, edge dependencies, and IAM reach are surfaced in context, ready for on-call, security reviews, and budget meetings.

  1. Unified visibility into compute and network resources. Sciple consolidates VPC peering routes, security group rules, elastic IPs, and load balancer targets into a single queryable view across every region and account, replacing tribal knowledge with an authoritative reference for incident response, security reviews, and architectural change.
  2. Workload-to-owner traceability across compute services. Sciple links every ECS task, EKS workload, Lambda function, and Step Functions execution back to the service catalog, so on-call engineers can identify the responsible team and the runtime location of a failing workload within seconds of an alert.
  3. Storage utilization and cost optimization. Sciple identifies unattached EBS volumes, idle RDS instances, abandoned S3 buckets, and underutilized ElastiCache clusters, providing the ownership and usage context required to safely reclaim spend and reduce exposure on dormant data stores.
  4. Change impact analysis for edge infrastructure. Sciple maps the dependency graph between CloudFront distributions, Route 53 records, cache policies, and load balancer targets, enabling teams to validate the blast radius of any edge or DNS change before it reaches production.
  5. IAM access review and least-privilege enforcement. Sciple surfaces unused roles, wildcard policies, orphaned instance profiles, and the workloads bound to each role, supporting continuous access review and right-sizing of permissions without disrupting active services.
  6. End-to-end deployment pipeline traceability. Sciple stitches CodePipeline, CodeBuild, CodeDeploy, and ECR activity into a single service-aware timeline, allowing teams to investigate failed deployments and trace ownership without traversing four separate AWS consoles.
  7. Workspace-isolated reads, always. Every query is scoped to the caller’s workspace at the database layer. There is no admin shortcut that bypasses the boundary, even for Sciple support.

Compute & networking

VPC peering, security groups, elastic IPs, and load balancer targets consolidated across every region and account.

Workloads

ECS tasks, EKS workloads, Lambda functions, and Step Functions resolved back to the service catalog and the responsible team.

Data & storage

Unattached EBS volumes, idle RDS instances, abandoned S3 buckets, underutilised ElastiCache flagged with ownership context.

Edge & DNS

Blast-radius analysis across CloudFront, Route 53, cache policies, and load balancers before any edge change.

Identity

IAM access review and least-privilege enforcement: unused roles, wildcards, orphaned profiles, workload-to-role bindings.

Code suite

CodePipeline, CodeBuild, CodeDeploy, and ECR activity in a single service-aware timeline.

Kubernetes

Production Kubernetes without the platform tax.

A managed Kubernetes operations layer as part of the platform. No separate console to install, host, patch, or upgrade. Every connected cluster is reachable through the same workspace, RBAC, and audit trail your teams use elsewhere.

  1. Zero-install operations. Manage and view resources across every connected cluster without standing up a separate management tool. Sciple is the console; there is nothing to deploy into the cluster beyond a credential.
  2. RBAC inherited from the workspace. Access flows through Sciple’s workspace permissions. Engineers see only the clusters and namespaces their role permits, with no kubeconfigs handed out by hand and no shadow service accounts to revoke later.
  3. Real-time cluster state. Workload state, pod phase, recent deploys, and cluster events stream live, giving operators an accurate picture at the exact moment they need it during an incident.
  4. Logs and pod shell on demand. Inspect logs and open a pod shell directly from the UI when investigation requires it. Every session is scoped to the engineer’s role and recorded in the audit trail.
  5. Release and revision visibility. Installed Helm releases, the values they were rendered with, and their revision history surface alongside the workloads they manage, so changes are traceable end to end.
  6. One audit trail, one identity. Every action (viewing a resource, reading logs, opening a shell, applying a change) lands in the same audit log as the rest of Sciple, tied to a single workspace identity rather than per-cluster credentials.

Operations

Zero-install. Sciple is the console; nothing to deploy into the cluster beyond a credential.

Access

RBAC inherited from the workspace. No kubeconfigs handed out, no shadow service accounts to revoke later.

Visibility

Workload state, pod phase, recent deploys, and cluster events stream live during incidents.

Debug

Inspect logs and open a pod shell directly from the UI. Every session scoped to role and recorded in the audit trail.

Helm

Installed releases, the values they were rendered with, and revision history surface alongside the workloads they manage.

Audit

Every action (view, log read, shell, apply) lands in the same audit log, tied to a single workspace identity.

CI / CD & Jobs

Serverless execution for pipelines, scheduled jobs, and ad-hoc tasks.

Sciple covers the full execution surface. Pipelines run on AWS CodeBuild. Scheduled cron jobs and ad-hoc one-shot tasks run as ECS Fargate tasks in your AWS account, or as Kubernetes Jobs and CronJobs on a connected EKS cluster. No managed CI vendor on your bill, no Jenkins, no separate scheduler to keep alive.

  1. Pipelines on AWS CodeBuild. Sciple’s CI/CD wrapper provisions the CodeBuild project and supporting permissions in your AWS account, runs the builds there, and ties every run back to the service that owns it.
  2. Templated, reusable pipeline configurations. Engineers define pipelines as parameterised templates shared across the workspace, with versioning and review built in.
  3. Service-and-environment scoping. Each pipeline is owned by a service-and-environment pair, so promoting from staging to production is a configuration change rather than a copy-paste.
  4. Approval gates per environment. Manual gates with named approvers, recorded in the audit trail alongside the run.
  5. Scheduled jobs on ECS Fargate. Cron jobs run as Fargate tasks in your AWS account on a schedule you define, with no servers to provision and no scheduler to babysit.
  6. Ad-hoc jobs on ECS Fargate. Run one-shot tasks on demand (migrations, backfills, data fixes, smoke checks) without standing up a long-lived worker fleet.
  7. Run on your existing EKS cluster. Prefer Kubernetes? Sciple can run scheduled and ad-hoc jobs as Kubernetes Jobs / CronJobs on a connected EKS cluster instead of Fargate.
  8. Shared execution surface. Builds, scheduled jobs, and ad-hoc jobs all share the same logging, audit, and ownership model. There is no second job runner to configure.
  9. No managed CI vendor, no Jenkins, no runner fleet. Execution lives in the AWS account you already operate, with workspace permissions and audit trail applied to every run.
  10. Per-run history and logs in the catalog. Status, logs, artifacts, ECR pushes, deploy targets, and the engineer who triggered the run are visible on the service’s catalog page.

Secret and Configuration Management

One surface for every secret and every config value your services depend on.

Sciple manages secrets and configuration as one queryable view per service. Secret values are backed by AWS Secrets Manager. Non-secret values are backed by AWS Parameter Store. Either way the values stay in your AWS account, plaintext env vars are not used, and the AI assistant cannot see them.

  1. Unified secret and config surface. Sciple manages secrets and configuration as one queryable view per service, instead of two separate tools your team has to reconcile.
  2. Backed by AWS Secrets Manager. Secret values stay in your AWS account. Sciple holds the reference, the expiry, the rotation schedule, the ownership, and the audit trail.
  3. Non-secret values in AWS Parameter Store. Plain configuration values are backed by Parameter Store, so the AWS-native control plane stays the source of truth.
  4. Four-level override hierarchy. Define defaults at the global, environment, and service level. The most-specific override always wins.
  5. No plaintext environment variables. Workloads pull values at runtime through the platform; nothing is materialised into a plaintext env var on disk.
  6. Reference by identifier, never by value. Other modules link to a secret or config entry by ID. The actual value never flows through the rest of the platform.
  7. Every credential kind your team operates. Passwords, API tokens, OAuth2 clients, SSH keys, TLS and GPG keys, AWS / Azure / GCP cloud credentials, GitHub Apps, GitLab and Bitbucket PATs, Kubernetes kubeconfig and service account tokens, container registry creds, webhook signing secrets, database connection strings, Slack and Teams bot tokens, and license keys.
  8. Rotation, expiry, and ownership tracked centrally. Every entry carries an expiry date, a rotation schedule, and an owner. Notifications fire when a secret is approaching renewal.
  9. AI assistant cannot see secret values. No tool in the assistant’s catalogue returns a secret or secret config value. The assistant works with references and metadata only.
  10. Full audit trail. Every read, write, rotation, and access-policy change lands in the same audit log as the rest of the platform, tied to a single workspace identity.

Security scanning & ASPM

Four scanning pillars. One ASPM workflow that gets findings fixed.

Sciple covers application security across four pillars. Code (SAST) runs static analysis, secret detection, and dependency scanning before the build. DAST probes live applications. Infra scanners audit containers, hosts, IaC, and Kubernetes. Cloud aggregates posture findings from AWS-native sources. Every finding flows into a single ASPM workflow with the owner attached through the service catalog.

  1. Severity, applied consistently. Critical, high, medium, low, and info, applied consistently across every scanner.
  2. Status visible at a glance. Open, in progress, suppressed, or fixed, visible across the queue and per finding.
  3. Owner, auto-routed. The service catalog sets the owner automatically, so a SAST finding in the checkout repo lands in the payments team’s queue without anyone having to assign it.
  4. Timeline on every finding. First seen, last seen, and last triaged are recorded against every finding.
  5. Suppression with reason and expiry. Every suppression carries a justification and a date when it expires back into the queue.
  6. Remediation linked to code. When a finding is fixed, the PR or commit that resolved it is attached, and the state transition lands in the audit trail.
  7. One-click triage. Each finding can be moved through the workflow in a single action, with the audit log capturing the engineer and reason.
  8. MTTR and trend reporting. Mean time to remediation by severity, team, and scanner, plus the findings-count trend per service.
  9. AI-assisted triage. The AI assistant groups related findings, suggests suppression candidates, and produces plain-English remediation guidance, without accessing scan results outside your workspace and without ever seeing credential values.

Code (SAST)

Static analysis, secret scanning, and SCA across npm, PyPI, Maven, Go modules, RubyGems, NuGet, Cargo.

DAST

Runtime probes for SQLi, XSS, broken auth, SSRF, IDORs. Service-aware, differential after each promotion.

Infra / Server

Container image CVEs across ECR / Docker Hub / GHCR / Quay, EC2 / Lambda via Inspector, Terraform / CloudFormation, Helm and K8s manifests.

Cloud

Posture findings from AWS Security Hub, GuardDuty, IAM Access Analyzer in the same queue as earlier-pipeline scanners.

Observability & Incident

Logs, metrics, traces, and incidents on one surface.

Sciple connects to the telemetry backends you already run (Elasticsearch, CloudWatch, Athena, Prometheus, Jaeger) and proxies every query through the platform. There is nothing to ingest and nothing new to store. The three pillars sit behind one identity, one audit trail, and the service catalog, alongside a native incident workflow that turns signals into a paged response, a status page update, and a postmortem.

  1. Unified per-service dashboard. Logs, metrics, and traces side-by-side per service, drawing from whichever backends the service uses.
  2. Native incident workflow. Declare an incident from any alert, finding, or failed pipeline. Severity, commander, and timeline are recorded from the first action.
  3. On-call rotations and paging. Schedules per team, escalations per tier, and a single paging path that respects the service catalog’s ownership.
  4. Status page, public or private. Customer-facing or workspace-internal status with auto-update from active incidents.
  5. Postmortem and follow-up tracking. Every incident produces a postmortem template; action items become tickets routed to the owning team.
  6. Optional sync with PagerDuty and Opsgenie. Keep your existing paging stack as the source of truth if you have one.
  7. No ingestion, no storage cost. Sciple stores connection config and queries your backends in place. Telemetry never leaves your infrastructure.
  8. Credentials from the central vault. Datasource auth (ApiKey, Bearer, HTTP Basic, mTLS, AWS keys, or assume-role) resolves from the credentials vault at query time, never stored inline and never returned to the browser.
  9. Connection health tracked. Every datasource records its last test result, latency, and error, so a broken source is obvious before an incident, not during one.
  10. Workspace RBAC and audit. Querying is gated by workspace permissions and datasource management is admin-scoped; every action lands in the same audit trail as the rest of the platform.

Logging

One Log Explorer across Elasticsearch (KQL / Lucene), CloudWatch Logs Insights, Athena over S3 archives, and live tail with level badges.

Monitoring

PromQL queries rendered as line, bar, stat, or gauge. CloudWatch namespace → metric picker. Host CPU / memory / disk / network from node_exporter.

Tracing

Distributed traces via Jaeger / Tempo. Filter by service, operation, time range. Span waterfalls. Traces resolve back to the catalog service that emitted them.

Dashboards

Composable panels over any registered data source: line, bar, stat, gauge, log. Drag-and-drop grid with a shared time-range selector. Export to JSON, Grafana-style.

Backups & DR

Backup tracking with failure alerts, attached to the service that owns the data.

Every AWS backup primitive in one inventory. Failed, skipped, and missing backups are surfaced and routed to the owning team. Restore tests, RPO and retention compliance, and the cost of backup storage are tracked per service. All backups stay in your AWS account.

  1. Every AWS backup primitive in one inventory. RDS automated and manual snapshots, EBS snapshots, AWS Backup vault jobs, S3 cross-region and cross-account replication state, DynamoDB point-in-time recovery, and EFS backups are tracked side-by-side in a single per-workspace view.
  2. Failed, skipped, and missing backups, flagged. Backup jobs that fail, get cancelled, miss their window, or never run are surfaced at the top of the queue and routed to the owning team. No more discovering a missing snapshot during a recovery drill.
  3. Routed through the service catalog. Every backup target is resolved to the service that owns the data. Alerts page the right team automatically, with no shared inbox to fish in.
  4. RPO and retention compliance, per service. Define recovery-point objectives and retention requirements per service or tier. Sciple flags every resource whose backup history violates the policy.
  5. Restore tests tracked end-to-end. Scheduled restore tests are tied to the backup plan that produced the recovery point. Restore success or failure becomes part of the audit trail and counts toward the service’s compliance posture.
  6. Lifecycle and lineage. Snapshot lineage per volume, retention schedules per plan, and the chain of backup-to-recovery events are queryable per service for the last 365 days by default.
  7. Cost visibility on backup storage. Backup vault storage, snapshot storage, and cross-region replication traffic are attributed to the owning service so the cost of a retention policy is never invisible.
  8. Full audit trail of every backup attempt. Every backup, restore, and policy change lands in the same audit log as the rest of the platform, tied to a single workspace identity. Auditors get an ordered timeline rather than a CloudTrail dig.
  9. Workspace-isolated, AWS-native. All backups live in your AWS account. Sciple holds the metadata and the audit trail; the actual recovery points stay in AWS Backup, RDS, EBS, or S3 where they belong.

AI assistant

An AI teammate that does not hallucinate your platform.

The assistant has structured tools that map one-to-one to platform endpoints. It uses platform feature knowledge plus resource metadata to help engineers solve problems and keep the platform aligned with compliance. By design, no tool in its catalogue returns a credential value or a secret config value.

  1. Platform navigator. Answers "how do I" questions about Sciple itself, grounded in your own runbooks, architecture docs, and workspace configuration.
  2. Natural language cloud queries. Ask the assistant about AWS or Kubernetes resources in plain English. The query is translated into platform tool calls, scoped to your workspace.
  3. Service scorecards with narrative. The assistant explains why a service is yellow or red, not just that it is, by joining catalog metadata, scanner findings, and recent activity.
  4. Cloud anomaly detection. Surfaces unusual cost shifts, drifted resources, and dormant workloads ranked by blast radius and ownership context.
  5. Kubernetes resource explainer. Hover any resource kind in the K8s browser and the assistant explains what it is, what depends on it, and what the safe rollback looks like.
  6. Compliance and hygiene guide. Maps your platform state to SOC 2 and ISO 27001 control families, then points at the specific findings that would block evidence.
  7. Triage assistant. Helps ASPM and incident workflows by grouping findings, suggesting suppression candidates, and drafting postmortem timelines.
  8. Cannot read secret values, by design. The assistant’s tool catalogue does not include any endpoint that returns a secret or secret config value. A clever prompt cannot trick it into surfacing one.
Meet the AI assistant

Runbooks

Remediation runbooks your team actually trusts.

Runbooks are notebook-style remediation playbooks. Each one is an ordered set of typed cells (markdown, shell, or HTTP) that target a Kubernetes namespace, an ECS service, or an EC2 instance. Draft a runbook, have an engineer review it, and promote it to a standard the whole team runs. Claude can author the first draft and generate the scripts, so the blank-page problem disappears.

  1. Typed cells: markdown for context, shell and HTTP for action
  2. Targets Kubernetes, ECS, and EC2
  3. Lifecycle from draft to reviewed to standard
  4. AI-authored drafts and scripts, with a human in the loop
  5. Run history with per-cell output

MCP server

Let Claude write the runbook. You approve it.

The Sciple MCP server exposes runbook authoring as tools your AI assistant can call. Run it locally through Claude Code or Claude Desktop with a scoped access token, then describe the procedure in plain language. Claude creates the runbook, adds the cells, and orders them by calling the platform directly. Nothing goes live until an engineer reviews and promotes it in the Sciple UI.

  1. Nine Claude-callable tools for runbooks and cells
  2. Runs locally over stdio via Claude Code or Claude Desktop
  3. Scoped personal access token, never your full credentials
  4. Claude drafts, engineers review and promote
  5. Built on the open Model Context Protocol

Dev Tools

Query your databases without sharing a password.

Dev Tools is a home for self-serve developer utilities. The first is the SQL Console: browser-based query access to the RDS databases in your own AWS account. Connect over an SSH bastion, an SSM session, or directly, and authenticate with IAM, which issues a short-lived token and stores no password, or with basic credentials held in the vault. Grant read-only or read-write access per person, and save the queries you run often.

  1. Browser-based SQL console for RDS Postgres and MySQL
  2. IAM auth with short-lived tokens, or vault-held basic credentials
  3. Reach databases over SSH, SSM, or a direct connection
  4. Read-only or read-write access profiles per person
  5. Private saved queries and schema introspection

AI automation

Automate operations through your AI assistant.

Runbooks, the MCP server, and the built-in AI assistant turn a plain-language request into a reviewed, repeatable operation.

Step 01

Describe it to Claude

Through the MCP server, ask your AI assistant to build a runbook in plain language. It creates the runbook and writes the cells by calling Sciple directly.

Step 02

Engineers review and promote

Nothing runs until a human approves it. Reviewers read the cells, refine them, and promote the runbook from draft to a team standard.

Step 03

The platform executes

Promoted runbooks run against your Kubernetes, ECS, and EC2 targets, with run history and per-cell output captured in the audit trail.

Native integrations

Plugs into the tools your team already operates.

Sciple is AWS-native and identity-agnostic. You do not rebuild your toolchain to adopt it. Connect your AWS account, your source-control provider, and your identity provider, and you are running.

0 native
integrations

Integrations directory · rev 2026.7

Wire your existing stack in once. Every integration shares the platform's identity model, audit trail, and workspace isolation from the first connection.

Full catalogue
  1. 01

    AWS

    27

    EC2 VPC EKS ECS Lambda Fargate Step Functions Auto Scaling RDS S3 IAM CodeBuild CodePipeline CodeDeploy CloudFront Route 53 Secrets Manager Parameter Store SSM ECR Athena OpenSearch (AWS) ElastiCache EFS EBS AWS Backup CloudTrail

  2. 02

    Container orchestration

    8

    EKS ECS Fargate Live pod updates Custom resources Helm charts Kubernetes Jobs / CronJobs Admission policies

  3. 03

    Source control

    6

    GitHub GitHub App GitLab (SaaS) GitLab (self-hosted) Bitbucket Azure DevOps

  4. 04

    Identity

    5

    Okta (OIDC) Entra ID Google Workspace Auth0 Any OIDC provider

  5. 05

    Observability & Incident Management

    11

    Prometheus Grafana Loki Jaeger OpenTelemetry Elasticsearch OpenSearch CloudWatch X-Ray PagerDuty Opsgenie

  6. 06

    Security scanning

    11

    SAST DAST SCA (dependency) Secret scanning Container image IaC (Terraform / CloudFormation) Kubernetes manifests AWS Security Hub AWS GuardDuty AWS Inspector IAM Access Analyzer

  7. 07

    Notifications

    4

    Slack Microsoft Teams Email Webhooks

Meet the Sciple assistant

The AI teammate that knows your platform.

The assistant knows every feature in Sciple and how the integrations wire together. It uses platform knowledge and resource metadata to help engineers solve problems and keep the platform aligned with compliance.

It never reads credential values, secret configuration, or your data plane. By design, the tool catalogue the assistant can call does not include endpoints that return secret material.

Ask the platform

"Show me all tier-1 services owned by the Platform Team that are missing a runbook."

Three tier-1 services are missing a runbook link.

The assistant lists each service with its owner and links you straight to the catalog page where you can add the runbook URL. It does not invent resources, and it does not surface secret values.

Who it is for

One platform, six roles. Pick the one closest to yours.

Sciple sits between every role that touches your engineering platform. Developers ship on it; platform engineers set the rules; security, operations, audit, and leadership read from the same source of truth.

Developers

Ship features without becoming a platform engineer.

Developers see one product that already knows their services. Push a commit and watch the pipeline, deploy, and observability stream in. Open the service catalog to find owners, runbooks, and dependencies. Ask the AI assistant "why is my pod restarting" and get a plain-English answer grounded in your platform, not a Stack Overflow guess.

  • One UI for catalog, cloud, K8s/ECS, pipelines, secrets, observability
  • Live pipelines and pod state without leaving the page
  • AI assistant that reads your platform, not your secrets
  • Self-service service creation, with no platform-team ticket needed
  • On-call gets logs + metrics + traces on one screen
See every feature →

Platform engineers

Set the policy. Let engineers ship.

Platform leads define the service catalog, the credential policy, the pipeline templates, and the permission model once. Engineers create services, configure them, and deploy from the same UI. The platform team stops being a ticket queue and starts shipping platform improvements.

  • Templated pipelines and service blueprints, governed centrally
  • RBAC with named groups, not strings scattered through the codebase
  • AWS Secrets Manager backed credentials, never on disk
  • Audit trail captures every mutation in the same transaction
  • Open HTTP API for everything you can do in the UI
Platform anatomy →

Security

Four scanning pillars. One ASPM queue. One audit log.

Security gets SAST, DAST, infra, and cloud-posture findings into a single ASPM workflow with the owner attached automatically through the service catalog. Secrets stay in your AWS Secrets Manager. Every access, every reveal, every rotation lands in the audit trail in the same transaction as the change.

  • Code, DAST, infra, and cloud-posture findings on one queue
  • Owner auto-routed from the service catalog
  • Credentials backed by AWS Secrets Manager, redacted in logs
  • Workspace isolation enforced at the query layer
  • Aligned with SOC 2 and ISO 27001 control families
Security & access →

Operations

On-call without tab-switching.

Operations sees the unified observability dashboard per service: logs from Loki / CloudWatch / Elasticsearch, metrics from Prometheus / CloudWatch, traces from Jaeger / X-Ray. Incidents declare from any alert. Status page auto-updates. Backups are tracked end-to-end, and failed snapshots page the right team.

  • Unified per-service dashboard for logs, metrics, traces
  • Native incident workflow with on-call rotations
  • Status page that auto-updates from active incidents
  • Backup tracking with failure alerts (RDS, EBS, AWS Backup, S3 replication)
  • Optional PagerDuty / Opsgenie sync
Observability →

Audit

Evidence on tap. Controls mapped to features.

Auditors get an ordered, greppable timeline of every action against every resource, with before-and-after snapshots, secret values redacted, and the workspace + identity recorded. The controls matrix maps every feature to its SOC 2 and ISO 27001 control. Evidence export is one click.

  • Every mutation written in the same transaction as the change
  • Before-and-after snapshots, with secrets redacted
  • Per-resource and per-user audit timeline
  • Controls matrix mapped to SOC 2 and ISO 27001
  • Evidence export for SOC 2, available on Enterprise
Audit & access →

Leadership

One place to see what you ship and what you run.

Service tiers, scorecards, audit trails, and cloud views are all in one dashboard. Engineering leadership stops paying for half-used tools that each see one slice of the picture. Sciple replaces the IDP, the cloud console, the ASPM tool, the secrets vault, the observability layer, and the on-call paging tool with one product that lives in your infrastructure.

  • Fourteen capability surfaces consolidated into one tool
  • Predictable line-item replacement: IDP + ASPM + observability + secrets + on-call
  • Runs in your AWS account, with no second control plane to fund
  • Service scorecards roll health, security, and compliance per team
  • 99.9% SLA on Business and Enterprise plans
Pricing →

FAQ

Frequently asked questions.

What makes Sciple different from other Internal Developer Platforms?

Sciple is one product with every capability your engineering platform needs already built in. The service catalog, documentation, project and ticket management, AWS cloud browser, Kubernetes and ECS view, CI/CD and jobs runner, secrets and configuration management, security scanning, observability, backup tracking, and AI assistant all share one identity model and one audit trail from the first connection.

Onboarding a new team scales to every feature at once. You do not need to integrate a registry tool with a pipeline tool with a secret store with a cost dashboard. They are the same product.

Can Sciple integrate with the tools we already use?

Yes. Sciple is built around AWS, with native coverage across every major AWS service family. Container orchestration covers both Kubernetes (EKS) and ECS. Source control runs through GitHub, GitLab, Bitbucket, or Azure DevOps. Identity is OIDC, so Okta, Entra ID, Google Workspace, and Auth0 all wire up directly. Observability stacks like Prometheus, Grafana, Loki, Jaeger, Elasticsearch, and OpenTelemetry plug in alongside CloudWatch and X-Ray.

Your existing ecosystem becomes searchable and auditable. You do not rebuild your toolchain to adopt Sciple.

How does Sciple help with cloud cost and resource hygiene?

Sciple surfaces unattached resources, idle EBS volumes, EIPs with no associations, EC2 instances sustaining under 5% CPU, Lambda functions with high memory and low invocation, and ECR repositories with no images. Each finding lands in a dashboard panel after every sync.

The AI assistant ranks findings by blast radius so platform teams know what to fix first.

Does the AI see our secrets?

No. The assistant operates on platform feature knowledge and resource metadata. It can see credential metadata such as kind, expiry, and which integrations reference a credential, but it cannot see the value.

By design, the tool catalogue the assistant can call does not include endpoints that return secret values. A clever prompt cannot trick it into surfacing one.

Which security scanners does Sciple include out of the box?

Sciple covers four scanning pillars. Code (SAST) includes static analysis, secret scanning, and dependency scanning (SCA across npm, PyPI, Maven, Go modules, RubyGems, NuGet, and Cargo). DAST tests live applications for runtime vulnerabilities. Infra and server scanning covers container images (across ECR, Docker Hub, GHCR, and Quay), running EC2 and Lambda hosts via AWS Inspector, Infrastructure-as-Code (Terraform and CloudFormation), and Kubernetes manifests and Helm charts. Cloud scanning pulls posture findings from AWS Security Hub, GuardDuty, and IAM Access Analyzer.

On top of the scanners, Sciple acts as an Application Security Posture Management tool. Every finding lands in a single workflow where your team can track its status, triage by severity and owner, and drive remediation to closure. The service catalog supplies the owner group automatically, so findings never sit unassigned.

Does Sciple support our compliance requirements?

Sciple is designed and operated to align with SOC 2 and ISO 27001 controls, with a controls matrix that maps each security feature to the relevant control. Audit trail, RBAC, single sign-on, AWS Secrets Manager-backed credentials, and strict workspace isolation are the building blocks. A formal SOC 2 Type II audit is on the roadmap.

Under NDA we share the controls matrix, the sub-processor list, and the standard CAIQ and SIG-Lite questionnaires.

What uptime SLA does Sciple offer?

Business and Enterprise plans come with 99.9% uptime SLAs. The Enterprise plan supports tailored agreements with custom support hours, dedicated customer engineering contacts, and named escalation paths for production-critical environments.

Book a 30-minute demo

A personalized tour of Sciple.

We will spin up a sandbox workspace, connect a sample AWS account, and walk you through the platform live. Bring your hardest platform problem.

What happens during the demo

  • See how Sciple unifies services, cloud, Kubernetes, and CI/CD in one product.
  • Walk through the built-in scanners and the ASPM track-and-triage workflow.
  • Explore how engineers self-serve a new service without writing YAML.
  • Walk through how to connect your AWS account in under 10 minutes.
  • Discover how the AI assistant answers platform questions safely.
  • Review the access model, audit trail, and SOC 2 / ISO 27001 mapping.

We respect your privacy. By submitting, you agree to be contacted by Sciple about your demo request.