Misting is the core resource management library at the heart of Mistcraft. It provides the runtime engine for tracking, planning, and deploying cloud infrastructure resources.

Unlike traditional Infrastructure as Code tools that are built as standalone applications with library capabilities added as an afterthought, Misting was designed from the ground up as a library. This architectural decision fundamentally shapes how you can use it: as an embedded component in your applications, as the engine behind a CLI tool, or as the foundation for your own infrastructure management solutions.

Philosophy and Design Goals

Misting is built around several core principles that distinguish it from other infrastructure management approaches.

Library-First Architecture

The primary design goal of Misting is embeddability. Traditional IaC tools require spawning external processes, managing inter-process communication, and dealing with process lifecycle complexities. Misting runs entirely in-process as a Rust library.

This means you can:

  • Import Misting as a cargo dependency and call its API directly
  • Share memory and context with your application
  • Handle infrastructure operations with the same error handling patterns as the rest of your code
  • Avoid the overhead and complexity of subprocess management

Infrastructure as Data

Misting treats infrastructure definitions as data structures rather than imperative code. You describe the desired state of your resources, and Misting determines what actions are needed to achieve that state.

This declarative model provides:

  • Predictability: The same definition always produces the same plan
  • Visibility: You can inspect and validate the plan before execution
  • Idempotency: Running the same definition multiple times converges to the same state

Two-Phase Evaluation

Misting separates evaluation into two distinct phases:

  1. Planning phase: Expressions are evaluated, but impure operations (like generating UUIDs or fetching current timestamps) return “unknown” values. This allows you to preview changes without side effects.

  2. Deployment phase: All expressions are fully evaluated, and actual cloud operations occur.

This separation enables safe previewing of changes before they happen, with full support for values that cannot be determined until deployment time.

Explicit State Management

Misting maintains an explicit record of managed resources through pluggable state backends. This state serves as the source of truth for:

  • What resources Misting has created
  • The last known configuration of each resource
  • The upstream-assigned identifiers for each resource

By tracking state explicitly, Misting can detect drift (when actual resources differ from recorded state) and calculate accurate change plans.

Mental Model: Infrastructure as Data, Not Code

The key insight behind Misting is that infrastructure definitions are fundamentally data, not programs. When you define a virtual machine or a database, you are describing properties and relationships, not executing steps.

Consider how you might think about a database resource:

Database:
  - name: "orders-db"
  - engine: "postgresql"
  - version: "15"
  - size: "medium"
  - depends_on: vpc.subnet

This is data. It describes what you want, not how to create it. Misting takes this data, compares it against current state, and determines the necessary actions (create, update, delete, or no change).

This data-centric model has practical implications:

  • Expressions evaluate to values: When you write an expression like concat(project_name, "-db"), it evaluates to a concrete value like "myapp-db". The expression is not executed at deployment time; the resulting value is used.

  • Resources are objects with properties: Each resource has a type, a reference (identity), and a set of property values. These are structured data, queryable and manipulable.

  • Plans are derived, not written: You do not write deployment steps. Misting derives the necessary actions by comparing desired state to actual state.

How Misting Compares to Other Approaches

Understanding where Misting fits in the IaC landscape helps clarify when and why you might choose it.

Compared to Terraform

Terraform is a standalone application with its own configuration language (HCL). Integration into applications requires:

  • Bundling the Terraform binary
  • Spawning it as a subprocess
  • Parsing stdout/stderr for results
  • Managing the Terraform process lifecycle

Misting, by contrast, is a Rust library. You add it as a dependency and call functions. There is no subprocess, no parsing of text output, and no separate binary to manage.

Additionally, Terraform’s state model is file-based by default. Misting provides pluggable state backends (filesystem, PostgreSQL, memory) with transactional guarantees where the backend supports them.

Compared to Pulumi

Pulumi offers an “Automation API” that allows programmatic control from general-purpose languages. However, the Automation API sits atop the same subprocess-based architecture as the CLI.

In practice, this means:

  • The Pulumi engine still runs as a separate process
  • State and secret management are tied to Pulumi’s service or self-hosted backends
  • Threading and async integration can be challenging due to the process boundary

Misting’s in-process design eliminates these boundaries. Your async runtime (Tokio) is Misting’s async runtime. Your error handling is Misting’s error handling.

Compared to AWS CDK and Similar

Cloud Development Kits (CDK) synthesize to underlying tooling (CloudFormation in AWS’s case). This means:

  • You write code that generates configuration
  • That configuration is then deployed by another tool
  • The synthesis step adds complexity and potential for divergence

Misting does not synthesize to another format. The Misting library directly interacts with cloud providers through its plugin system. There is no intermediate representation that might drift from your intent.

Compared to Direct API Usage

You could, of course, call cloud provider APIs directly. This gives maximum control but requires you to:

  • Track what resources you have created
  • Detect changes and calculate diffs
  • Handle ordering and dependencies
  • Manage idempotency and error recovery

Misting provides these capabilities as a library. You get the control of direct API access with the convenience of managed state and change detection.

When to Use Misting

Misting is particularly well-suited for scenarios where infrastructure management must be integrated into larger systems.

SaaS Platforms Provisioning Customer Infrastructure

When your SaaS product needs to provision isolated infrastructure for each customer (databases, networks, compute resources), Misting can run as part of your application. No external processes, no shell commands, just function calls.

Platform Engineering Tools

If you are building internal developer platforms, deployment pipelines, or infrastructure automation tools, Misting provides the building blocks. You can compose it with your own authentication, authorization, and orchestration logic.

Custom Infrastructure Management Solutions

When standard IaC tools do not fit your workflow, Misting’s library design lets you build exactly what you need. You control the user interface, the execution model, and the integration points.

Applications with Dynamic Infrastructure Needs

For applications that must create and destroy infrastructure at runtime (test environments, ephemeral workloads, scaling operations), embedding Misting avoids the overhead of shelling out to external tools.

What Misting is NOT

Understanding what Misting does not do is as important as understanding what it does.

Not a Standalone CLI Application

Misting is a library. It does not come with a command-line interface. If you want CLI functionality, use Mistup (which uses Misting internally) or build your own CLI around Misting.

Not a Configuration Language

Misting is a Rust library, not a configuration syntax. It can be used with Mistwrite (a declarative DSL) or programmatically from Rust code. But Misting itself does not parse configuration files.

Not a Cloud Provider

Misting does not communicate with cloud providers directly. It relies on plugins (like the Azure plugin) to handle provider-specific operations. Misting provides the orchestration; plugins provide the cloud connectivity.

Not a Secrets Manager

While Misting can mark values as sensitive and will avoid logging them, it does not store or manage secrets. Use a dedicated secrets management solution and provide secrets to Misting at runtime.

Not a Replacement for Understanding Cloud Resources

Misting helps you manage resources, but you still need to understand the resources you are managing. Misting will not prevent you from creating insecure configurations or making expensive mistakes. It executes the plan you define.

The Misting Value Proposition

The fundamental value of Misting is control. You get the benefits of managed infrastructure state and change planning without surrendering control of your application’s execution model.

If you need to:

  • Embed infrastructure management in an application
  • Build custom deployment workflows
  • Integrate with existing Rust codebases
  • Have fine-grained control over when and how deployments happen

Then Misting provides a foundation designed for exactly these requirements. It is the infrastructure management library that treats being a library as its primary purpose, not an afterthought.