Pre-alpha Taking on a few design partners

Ship and run your product. Skip the platform team.

Describe your services and what they need in a few lines of TypeScript or Python. Insular OS runs them locally, deploys them into your own AWS account, and shows you what is deployed and how it runs. Your AI assistant can do all of it too.

Run locallyins dev

Every service, every store and tracing, from one command.

Previewins deploy --plan

A read-only plan against your account, with a cost floor.

Ship & verifyins deploy show

Done only when every service is up and healthy.

Tear downins down

Removes it all, then sweeps for anything still billing.

Design · chat-app
The platform's design view: services, a web app and jobs placed in an AWS account and VPC, wired to RDS Postgres and ElastiCache Valkey
The platform

Your code becomes a palette. Your cloud becomes a canvas.

Every service, web app and job in your code shows up ready to place in a design. Drop them into an AWS account and VPC, and each declared need is answered by a real managed service.

  • chat-dbdatastore, answered by RDS Postgres
  • chat-cachekv, answered by ElastiCache Valkey
  • agent ^1.0.0a contract, wired to the service that serves it
Less to write, less to debug

Most infrastructure work is one line. Or none.

The job
Without Insular OS
With Insular OS
Let an AI agent call a service
Stand up and host an MCP server
One line on the service: mcp: [{ handler: 'respond', tool: 'agent_respond' }]
Get infrastructure into the cloud
Write, review and debug Terraform
None written. It is generated from the description.
Give a service a database
Provision it, wire the connection string, keep dev and prod alike
Declare Postgres.create({ schema }) and list it under requires
Configuration and secrets
.env files, CI variables and a secrets manager that drift apart
Declared once with Settings.create, answered in one place with ins settings, secrets encrypted
A missing setting
Found in production, as a crash
Refused before startup, naming the key and how to answer it
See what a change will cost
Read a plan by hand, estimate later
Plan and cost floor before anything is applied
Clean up
Hunt for what is still billing
ins down, then a sweep of the account
What you write

This is the whole service.

A Postgres store with its schema, typed settings, a contract, and an implementation that declares what it needs. There is no separate infrastructure file.

  • Postgres.createA real database locally and RDS on AWS, from one declaration.
  • Settings.createTyped with Zod. A missing key stops the run before it starts.
  • Service.contractTyped inputs and outputs that other services and agents call.
  • requiresEverything the service needs, injected at runtime.
  • mcpTurns a method into an MCP tool for your agents.
services/agent.ts
const messages = pgTable(
  'messages',
  {
    id: text('id').primaryKey(),
    authorName: text('author_name').notNull(),
    authorKind: text('author_kind').notNull(),
    body: text('body').notNull(),
    createdAt: timestamp('created_at', { withTimezone: true }).notNull(),
  },
  (t) => [index('messages_created_at').on(t.createdAt)],
);

export const MessageStore = Postgres.create({ schema: { messages } });

export const AgentSettings = Settings.create(z.object({
  apiKey: z.string(),
  model: z.string(),
  systemPrompt: z.string().default(DEFAULT_SYSTEM_PROMPT),
}));

export const AgentContract = Service.contract('agent', {
  methods: {
    respond: {
      input: z.object({
        prompt: MessageSchema,
        history: z.array(MessageSchema),
      }),
      output: z.string(),
    },
  },
});

export const AgentService = Service.implement(
  AgentContract,
  {
    requires: {
      db: MessageStore,
      other: OtherContract,
      settings: AgentSettings,
    },
    mcp: [{ handler: 'respond', tool: 'agent_respond' }],
  },
  ({ db, other, settings }) => ({
    respond: async ({ history, prompt }) => {
      const agent = createAgent(settings);
      await Promise.all([
        db.insert(MessageStore.messages).values(toMessage(prompt)),
        other.doSomething(),
      ]);
      // ... your special sauce
      return '';
    },
  }),
);
Everything here runs today

From laptop to production, and back down again.

ins dev

Your whole product, locally, with one command.

Every service, every store and the platform beside them, with tracing on from the first request.

  • A real container for each store: Postgres, Valkey, MongoDB, S3.
  • One front door for the web app, its routes and every service method.
  • Traces, metrics and logs in a dashboard at /.dev/observe/.
  • Secrets are encrypted on your machine and never leave it.
/.dev/observe
A trace of GET / across the web, chat and agent services, down to the SQL statement

One page load traced across three services, down to the SQL, in 27.5 ms. No instrumentation code.

ins deploy --plan

See the plan and the cost before you deploy

The same description that runs locally deploys into your AWS account, with no Terraform written by hand.

  • A real, read-only plan with a cost floor
  • Multi-step changes, like a database swap, previewed step by step
  • Nothing applies until you type the account id at the gate
ins deploy show

Know what is deployed and whether it is healthy

Every deploy is recorded, and it only counts as done when the system is actually up.

  • Steps, stacks and gate for every deploy; ins deploy events for the log
  • Readiness gate: every service running and healthy for two minutes straight
  • A deploy that misses the gate is recorded as failed, not left half up
ins catalog show

Say what you need. The catalog picks the technology.

A service asks for a kind of store, and the catalog decides which engine answers it in each place it runs.

  • A container locally, the managed service on AWS
  • Postgres, Valkey, S3 and MongoDB, with MongoDB Atlas as a cloud option
  • Pin a different engine per store at deploy time
ins down

Teardown that actually stops the meter

One command removes everything a project deployed, then checks the account for anything that survived.

  • Destroys each deployment from its own recorded state
  • --sweep-only lists what is running and costing money right now
ins env create

A sandbox per branch, for people and for agents

Each environment is its own Linux VM with a clone of your repo on a branch, on macOS or Linux.

  • Hand it a task and a coding agent works it, ending in a commit
  • Traffic leaves only through a proxy; no secret is ever inside the VM
  • ins env fetch brings commits back for review; a tray app for non-terminal folks
ins settings

Configuration in one place

Settings are declared once in code and answered in one place, with secrets encrypted.

  • A missing setting is refused before startup, naming the key
  • The same answers locally and in the cloud
Built for your coding agents

Your running system speaks MCP.

An agent can read it and drive it the way an engineer would: read logs and traces, call any method, preview a change and explain what will happen. Anyone on the team can work through a complex deployment by asking their assistant.

/.dev/mcpEvery service method as an MCP tool, plus processes, logs, traces, metrics and SQL over the telemetry.
/.platform/mcpProjects, catalogs, designs and deployments.
/.dev/<service>/<method>A call surface for every method, so you can call anything by hand.
No lock-in

Keep the tools you already use.

Nothing moves onto a new hosting platform. It deploys standard managed services into an account you own.

Your cloud account

Deploys into your AWS account. See and keep every resource it makes.

Your data stores

The real services, not a proprietary layer.

PostgresValkeyS3MongoDB
Your observability

Traces, metrics and logs are OpenTelemetry from the first request.

Your code

TypeScript or Python, with libraries you know.

DrizzleZod
Grow without a platform team

The people you have can do the infra work.

As you add customers, the work that usually needs infra and platform hires is handled by the system.

Full-stack engineers

Ship with best practices built in: a plan before every deploy, a typed gate before anything costs money, a readiness check after, and a clean teardown.

Sales and forward deployed engineers

Stand up and tear down a deployment themselves, with the plan and cost in front of them, instead of waiting on engineering.

Anyone with an AI assistant

The running system and the platform are both MCP servers, so the assistant can read logs and traces, preview a change and explain it.

Designed, not built yet

What's next on the roadmap.

Everything above runs today. These are specified and planned, and we won't show them as working until they do.

Delivery

One design installed per customer, with releases and fleets, for products delivered into customer clouds.

Targets

Kubernetes and GCP as deploy targets.

Access

Sign-in and roles on a deployed platform.

Migration

Online moves of a running system between clouds with no downtime. The step preview exists; the move does not.

Agents

Agent needs as first-class parts of a design: a model gateway, sandboxed execution and human approval.

Compliance

A compliance console for regimes like SOC 2, HIPAA and GDPR.

Design partners

Ship to your first customers without hiring a platform team.

We're working hands-on with a small number of teams to map their product onto Insular OS. A good fit looks like this:

  • A few months from launchYou're getting close to shipping to your own customers.
  • Facing the infra hireYou'd otherwise need infrastructure, application or security people.
  • Starting small is fineAn internal service is a great first project.