Vizier: The IaC Orchestrator That Connects Provisioning to Day-2 Ops

Infrastructure as Code has long promised to eliminate the gap between provisioning and ongoing operational management, yet most teams still find themselves context-switching between Terraform runs, Helm charts, and a fragmented collection of day-2 tooling that never quite speaks the same language. The seams between initial deployment and long-term operations remain stubbornly visible, and the cognitive overhead compounds as systems scale.

Vizier enters this space as something more deliberate than another abstraction layer. Positioned as an IaC orchestrator, Vizier is designed to maintain continuity between the moment infrastructure is provisioned and everything that follows: drift remediation, policy enforcement, dependency-aware updates, and lifecycle management across heterogeneous environments.

In this analysis, we examine how Vizier architecturally bridges that persistent operational gap, what its execution model looks like under the hood, and where it meaningfully differs from adjacent tools in the orchestration landscape. We will also explore the tradeoffs practitioners should weigh before adopting it at scale. If you are operating infrastructure beyond the point where runbooks and shell scripts are sufficient, the design philosophy behind Vizier is worth understanding carefully.

The IaC Fragmentation Problem No One Has Fully Solved

The infrastructure-as-code landscape in 2026 is not a tooling problem. It is a coordination problem masquerading as one. According to top IaC tools analysis from Firefly Academy, modern IaC spans five distinct operational layers: provisioning, configuration, deployment, scaling, and governance. Each layer has its own dominant toolchain, its own state model, its own failure modes, and critically, its own team ownership boundaries. When a provisioning pipeline completes and hands off to a configuration management workflow, that boundary is where misconfiguration incidents are born. These handoff failures are not edge cases. They are structural properties of architectures built from non-composable, layer-specific tooling.

The fracture lines deepened significantly in 2023 when HashiCorp moved Terraform from the Mozilla Public License to the Business Source License. What followed was not a clean migration. Teams mid-lifecycle with established module libraries were forced to audit every dependency, evaluate OpenTofu compatibility, and in many cases rebuild module catalogs from scratch under new licensing assumptions. By 2026, Terraform and OpenTofu are treated as co-incumbent provisioning engines, a bifurcated baseline where neither fully dominates. The practical consequence for engineering teams is a module ecosystem that is split, partially verified, and inconsistently maintained across both forks. Any organization that invested heavily in a Terraform module library before the BSL change now carries technical debt that compounds with every new environment they provision.

Platform engineering's maturation has added a third dimension of pressure. The discipline has advanced from an aspirational organizational model to a formal category tracked in analyst frameworks, with Internal Developer Platforms now expected to expose IaC as a self-service primitive rather than a specialist capability. The core diagnosis is precise: raw IaC authorship is bottleneck work, accessible only to a narrow group of practitioners, and that bottleneck blocks developer velocity at scale. IDPs require the underlying infrastructure modules to be composable, independently trustworthy, and consumable without deep Terraform or OpenTofu expertise. Bespoke per-team toolchains cannot satisfy that requirement because they are, by definition, not composable across organizational boundaries.

The provisioning-to-Day-2 configuration gap deserves specific attention because it remains structurally unresolved by open-source tooling. Terraform and OpenTofu provision resources. Ansible configures systems post-provisioning. These tools operate at different altitudes in the stack, with no native handoff protocol between them. A HashiCorp technical session from March 2026, dedicated entirely to the "provisioning to Day-2 operations" integration challenge, confirms this is an active operational problem, not a solved one. The Terraform vendor itself is producing content to address a gap its own toolchain does not close natively.

Manual cloud management is no longer a viable operating model at enterprise scale, and the failure mode is quantitative, not philosophical. Misconfiguration risk, environment drift, and cost overruns do not scale linearly with team size. They scale with infrastructure complexity. As noted in IaC best practices research from GartSolutions, organizations that treat IaC as an afterthought consistently struggle with scale, security, and reliability. Adding headcount to a fragmented toolchain does not reduce the surface area for drift; it increases the number of operators who can introduce it. Orchestration, at this point, is not a productivity feature. It is a structural requirement for maintaining operational integrity across distributed, multi-layer infrastructure at any meaningful scale.

What Vizier Actually Is (And What Makes It Structurally Different)

Vizier is not a pipeline runner with module support bolted on as an afterthought. It is an orchestrator purpose-built to execute against IaC Bazaar's curated catalog of Terraform, OpenTofu, and Ansible modules, where every artifact in that catalog has been statically validated, security-scanned, and cosign-signed before it is ever available for orchestration. That distinction matters more than it might initially appear. Generic workflow engines accept whatever modules you point them at, which means the quality and safety of your execution graph is only as good as the modules you sourced and vetted yourself. Vizier inverts this model entirely: the verification work happens upstream of your pipeline, not downstream of a production incident.

The Catalog-Backed Execution Model

The architectural decision that separates Vizier from a conventional orchestration approach is the tight coupling between the orchestrator and a pre-validated module catalog. When Vizier constructs an execution graph, it is drawing exclusively from IaC Bazaar's verified inventory. Every module available for selection has already cleared static analysis, passed supply-chain validation, and carries a cosign signature that provides cryptographic proof of provenance. This is not an optional security layer you configure after onboarding; it is a structural precondition of how the catalog operates. The practical consequence is that the attack surface introduced by unverified community modules, a well-documented vector in IaC supply-chain risk, is removed from consideration at the point of module availability, not at the point of deployment review.

A Concrete Execution Walkthrough

Consider what provisioning a production EKS cluster looks like inside this model. An engineer opens the catalog, selects verified EKS and supporting networking or IAM modules, and Vizier constructs the provisioning sequence using Terraform or OpenTofu as the execution engine. Once the infrastructure layer is provisioned, Vizier continues the workflow into the configuration layer, chaining Ansible modules from the same verified catalog to handle node configuration, software installation, and Day-2 setup. This is a single coordinated execution model, not two separate workflows bridged by a manual handoff or a bespoke CI script. The unification of provisioning and configuration under one orchestrated run is precisely the gap that the broader IaC ecosystem has struggled to close, given that Terraform and Ansible have historically been operated as parallel disciplines by separate team segments.

Engine-Agnostic, Workflow-Stable

For teams that moved away from Terraform following the 2023 BSL license change, the migration path into Vizier carries a meaningful engineering advantage. Both Terraform and OpenTofu are treated as first-class provisioning engines within the orchestrator. Switching from one to the other does not require rebuilding the workflow layer or re-mapping module dependencies; the orchestration logic remains stable while the underlying engine changes. This is a significant operational consideration for platform engineering teams who invested in standardized workflow patterns and cannot absorb the cost of redesigning orchestration from scratch alongside a toolchain migration.

The net result of this architecture is the elimination of what practitioners sometimes call the "works on my machine" module problem. Because every module in the execution graph was verified before it entered the catalog, and because the catalog is the only source Vizier draws from, environment-specific inconsistencies introduced by unvalidated or inconsistently packaged modules are structurally prevented rather than reactively diagnosed.

The Supply-Chain Security Argument for Verified IaC Modules

The threat model for IaC module consumption is structurally identical to the broader software supply-chain attack surface, and the consequences of ignoring it are proportionally severe. When a team pulls a Terraform module from a community registry, they are executing third-party code with direct provisioning authority over their cloud environment. A malicious actor who introduces a backdoored module, or a well-intentioned maintainer who publishes one with misconfigured IAM policies or open security group definitions, creates a vulnerability that propagates silently to every downstream consumer. As Palo Alto Networks documents in their IaC supply-chain security analysis, IaC supply-chain attacks target the templates, modules, and pipelines used to provision cloud infrastructure, meaning a single compromised module can affect every environment that references it. The insidious quality of this attack vector is its consistency: IaC's greatest operational strength, repeatability, becomes its greatest security liability when the artifact being repeated has not been verified.

Cryptographic Attestation as a First-Class Control

IaC Bazaar addresses this threat at the artifact layer through Cosign signing, the signing tool that forms the cornerstone of the Sigstore ecosystem and aligns with the Supply-chain Levels for Software Artifacts (SLSA) framework's provenance attestation principles. Cosign provides cryptographic proof that a specific module artifact has not been modified between the point of publication and the point of execution. This is not a policy control or an organisational process; it is a machine-verifiable signature that a CI pipeline can validate before a single terraform apply or Ansible playbook run is permitted to proceed. Community registries, including the public Terraform Registry, do not offer this guarantee by default. Modules may be versioned and tagged, but the registry does not bind a cryptographic identity to the artifact in a way that downstream consumers can independently verify. The gap between "a version exists" and "this artifact is cryptographically attested to match what passed our validation pipeline" is precisely the gap that supply-chain attacks exploit.

Pre-Catalog Static Validation

Beyond signing, the IaC Bazaar verification pipeline enforces static validation as a precondition for catalog inclusion, not as a post-hoc check. Every module is evaluated for syntax correctness, deprecated resource patterns, and policy violations before it becomes available to Vizier as an orchestration target. This sequencing is analytically significant. The 8 best practices for securing IaC published by Cycode consistently reinforce that scanning must occur before provisioning, not after a failed apply, because the remediation cost of post-deployment misconfigurations rises sharply once infrastructure is live. Static validation at catalog ingestion operationalises this principle at the registry layer itself, rather than delegating the responsibility to individual teams who may or may not have configured their own pre-apply scanning.

Blast Radius Reduction Through Pipeline-Level Security Scanning

The verification pipeline also incorporates security scanning that operates at the module level, catching the categories of misconfiguration most likely to produce exploitable infrastructure. Overly permissive IAM policies, open security groups, and unencrypted storage declarations are among the most documented IaC failure patterns, and they are all detectable through automated static analysis before a module is ever executed. By catching these at the catalog layer, IaC Bazaar reduces blast radius in a way that per-team scanning cannot fully replicate: a team that consumes a verified module does not need to independently re-validate IAM scope or storage encryption settings because that validation is already documented, repeatable, and tied to the signed artifact.

The Verifiable Difference from Community Modules

The practical distinction between an IaC Bazaar verified module and a community-sourced alternative resolves into three concrete properties. Provenance is documented: the validation pipeline records what checks were run and when. The pipeline is repeatable: the same checks will execute identically for every module version submitted to the catalog. The cosign signature is machine-verifiable in CI: any pipeline consuming IaC Bazaar modules can independently confirm artifact integrity without trusting the registry on faith alone. Community modules, regardless of their technical quality, offer none of these guarantees by default. This is not a criticism of community maintainers; it is an architectural observation about what community registries were designed to provide. Vizier's catalog-backed orchestration model is built on the premise that production infrastructure deserves a higher evidentiary standard than "the module exists and the README looks reasonable."

Vizier vs. the Field: How It Compares to Existing Orchestration Tools

Vizier vs. Terragrunt

Terragrunt remains one of the most widely deployed Terraform wrappers in production environments as of 2026, and its longevity is deserved within its defined scope. It solves real problems: DRY configuration patterns, remote state management, and module composition across environments. However, framing Terragrunt as an orchestrator misrepresents what it actually does. It operates strictly as a Terraform wrapper, with no native awareness of the provisioning-to-configuration handoff that separates Day-1 from Day-2 operations. Teams relying on Terragrunt still source modules manually from public registries, verify integrity through informal processes, and handle Ansible coordination through entirely separate toolchains. There is no supply-chain security layer, no cosign-based signing, and no curated catalog enforcing static validation before a module reaches production. Vizier's catalog-backed orchestration model closes every one of these gaps in a single surface, which Terragrunt's architecture was never designed to address.

Vizier vs. Crossplane

Crossplane occupies a genuinely powerful position in the 2026 IaC landscape for teams that are already Kubernetes-native. Its model of treating infrastructure as Kubernetes custom resources enables strong GitOps integration and declarative lifecycle management. The structural constraint, however, is not a minor implementation detail; it is a fundamental architectural prerequisite. Crossplane requires a running Kubernetes cluster as the control plane itself. For organizations that have not standardized on Kubernetes, adopting Crossplane means first building and operating the control plane before provisioning a single infrastructure resource through it. That is a meaningful barrier, particularly for teams managing hybrid environments or legacy workloads where K8s adoption is partial or absent. Vizier has no equivalent runtime dependency. It operates against IaC Bazaar's verified catalog without requiring a cluster, a running controller, or a pre-existing platform engineering layer to stand it up.

Vizier vs. Enterprise Automation Platforms

The enterprise orchestration tier in 2026 is well-populated. Platforms in this category offer sophisticated Terraform lifecycle integration, drift detection, policy enforcement, and approval workflows. The best IaC tools analysis from SentinelOne confirms these platforms have matured considerably, with multi-IaC support and audit-grade observability. What they also share, uniformly, is a subscription-based commercial model that requires meaningful onboarding investment, organizational buy-in, and ongoing licensing costs. The platform itself becomes a dependency; migrating off introduces its own operational cost. None of these platforms are documented as embedding cryptographic module signing at the distribution layer. Vizier's per-module pricing, starting at $29 with no subscription requirement, is not simply a cheaper alternative; it is a structurally different model that removes vendor lock-in at the contract level before a single module is deployed.

The Five-Dimension Gap Analysis

When evaluated across the five dimensions that matter most to infrastructure teams operating at scale in 2026, a clear picture emerges. The dimensions are: curated module catalog, supply-chain security via cosign signing, native Ansible coordination, per-module pricing without subscription, and Day-2 operations support. Terragrunt scores positively on none of the first four. Crossplane addresses Day-2 operations within its Kubernetes-scoped model but fails on catalog, signing, Ansible coordination, and pricing model. Enterprise automation platforms handle Day-2 operations and offer partial Ansible support in some configurations, but carry zero scores on supply-chain security and per-module pricing. Vizier scores positively across all five simultaneously. That is not a marginal differentiation; it reflects a genuinely distinct architectural position.

The Defensible Whitespace

A thorough survey of current IaC tooling for cloud automation confirms no open-source or commercial tool currently combines a cosign-signed, statically validated module marketplace with a native orchestration layer. Supply-chain security for IaC is an emerging but insufficiently addressed concern in 2026, and the gap between awareness of the problem and tooling that solves it structurally remains wide. Vizier's combination of verified module provenance, multi-tool orchestration across Terraform, OpenTofu, and Ansible, and a no-subscription consumption model occupies a position that is not currently replicable by any identified competitor. For engineering teams re-evaluating their stacks in the post-BSL licensing environment, that combination is precisely where the market has an unfilled gap.

Production-Ready Stacks for AWS, EKS, and GKE: What Curated Means in Practice

The term "curated" is doing significant architectural work in IaC Bazaar's product positioning, and it deserves precise unpacking. A curated stack for AWS, EKS, or GKE is not a bundled collection of individual modules handed to the buyer as raw ingredients. It is a pre-assembled, tested production topology in which the modules have been validated against each other, sequenced into a coherent execution order, and confirmed to produce a working infrastructure target. The integration layer, which is typically where days of engineering effort disappear on self-assembled stacks, is part of the product.

The Integration Tax of Building From Scratch

Consider the surface area of a production-grade EKS stack assembled independently. An engineering team must source separate modules for the cluster itself, managed node groups, VPC and subnet configuration, IAM roles and IRSA bindings, and the add-on layer covering components like the AWS Load Balancer Controller, EBS CSI driver, and cluster autoscaler. Each module arrives with its own interface contracts, variable schemas, and implicit assumptions about what upstream modules have already configured. Validating that these modules compose correctly, testing them as a system across multiple scenarios, and aligning them against AWS current best-practice guidance is realistically a multi-day exercise before a single application workload runs. IaC Bazaar's curated EKS stack compresses this from an open-ended integration project into a verified starting point with a known, tested topology. Per AWS re:Invent platform engineering guidance for EKS, reusable, pre-assembled blueprints are the mechanism by which platform teams enable reliable infrastructure delivery at scale, a framing that directly validates the curated stack model.

Orchestration as the Deliverable

The GKE production stack available through Vizier illustrates the architecture most concretely. The stack chains pre-validated networking modules, cluster configuration, workload identity bindings, and Ansible post-provisioning tasks in a tested execution order. Vizier, as the orchestrator, is responsible for driving this sequence correctly across both Terraform provisioning and Ansible configuration layers. The critical point is that the orchestration itself is what the team is acquiring. Anyone can download a networking module and a cluster module separately; the tested, validated execution graph connecting them is the engineering investment that a curated stack makes available as a reusable artifact. AWS reinforces this directly: building reusable EKS blueprints at scale is framed as a platform engineering discipline, not a provisioning shortcut.

Maintenance Against Living Best Practices

Community-published modules frequently reflect the security and architecture guidance that was current at the time of authorship. The managed Kubernetes ecosystem moves faster than community maintenance cadences: EKS and GKE both evolve across networking models, node group configurations, security primitives, and workload identity patterns on timelines measured in quarters. IaC Bazaar's curated stacks are maintained in alignment with current cloud provider recommendations, meaning a stack downloaded in Q1 carries guidance that reflects the state of AWS or GCP architecture recommendations at that time, rather than a snapshot frozen at community publication date.

The Internal Developer Platform Use Case

For platform engineering teams building Internal Developer Platforms, the curated stack model serves a specific structural function. Rather than exposing developers to the full configuration surface area of a Kubernetes environment, platform teams can present Vizier's curated stacks as the authoritative, organization-vetted baseline. The 2024 O'Reilly Infrastructure Survey found that 68% of organizations now prioritize multi-cloud flexibility and cost optimization in IaC tooling selection, up from 42% in 2021; organizations operating at that level of infrastructure scale need governed building blocks, not open-ended module libraries. Curated stacks reduce the decision surface developers encounter when self-serving infrastructure requests, while keeping security and architecture decisions centralized with the platform team that has the context to make them correctly.

The Economics: Per-Module Pricing vs. Everything Else

The pricing architecture behind IaC Bazaar reflects a deliberate philosophical position: the unit of value in infrastructure tooling is the module itself, not the seat count of a team consuming it. Modules in the IaC Bazaar catalog start at $29 per module with no subscription required, meaning procurement decisions are scoped to exactly the capability being acquired. A platform engineer sourcing a verified EKS node group module makes a discrete purchasing decision bounded by that module's cost. There is no platform tier to negotiate, no annual contract to route through legal, and no minimum seat commitment that inflates the budget ask before a single line of infrastructure code runs in production.

The Hidden Cost of Building Internally

The DIY alternative is rarely costed with full fidelity. Engineering teams that build Terraform modules internally tend to account for initial development time while systematically underweighting the full lifecycle burden. Writing a production-grade module involves not just authoring HCL but designing input variable schemas that survive real-world variation, writing test harnesses, conducting security review against misconfig patterns like open ingress rules and overly permissive IAM policies, and establishing a maintenance process for upstream provider changes. Priced at market-rate senior engineering time, the honest cost of a single verified, maintained module routinely falls between $500 and $2,000 when accounting for initial build and ongoing upkeep across provider version cycles. That figure compounds across a catalog of even modest size. A platform team assembling 20 modules internally is absorbing a cost that dwarfs the equivalent verified catalog acquisition, while simultaneously deferring the security validation and attestation work that IaC Bazaar's pipeline handles as part of the base offering.

Where Enterprise Platform Pricing Breaks Down

The alternative to per-module acquisition is typically an enterprise IaC platform with annual contracts priced on per-seat or per-node models. The cost curve in these models scales against team growth and organizational headcount, not against the scope of infrastructure being managed. According to Terraform Cloud pricing analysis, enterprise tiers require direct sales engagement and custom annual pricing, with the free tier having ended in March 2026 as confirmed by infrastructure teams evaluating post-BSL alternatives. This creates a structural misalignment: a team whose infrastructure scope is stable but whose headcount grows pays more, not because the infrastructure got more complex, but because the pricing model treats people as the billable unit rather than the modules they consume.

Fit for Platform Engineering Workflows

Per-module economics are particularly well-aligned with how platform engineering teams actually assemble Internal Developer Platforms. An IDP is constructed from specific building blocks selected to match the organization's cloud footprint and operational requirements. A team building on AWS EKS does not need a verified module catalog covering every GCP service; they need the specific verified modules that compose their platform's infrastructure layer. Committing to a monolithic platform contract to access a subset of capabilities introduces budget overhead for functionality that will never be used. The per-module model allows teams to source precisely what the IDP requires, with each module carrying its own verification provenance, without paying for catalog surface area that sits idle.

This granularity also meaningfully reduces procurement friction for individual infrastructure engineers. As noted in the production-ready IaC guide from IaC Bazaar, 68% of organizations now prioritize cost optimization as a primary IaC selection criterion, up from 42% in 2021. When an engineer needs a specific verified module for a project, the purchase decision fits within discretionary spend thresholds rather than requiring a platform-level budget approval cycle that can delay project timelines by weeks.

Where Vizier Fits in Your 2026 IaC Strategy

The five use cases below are not hypothetical positioning exercises. They map directly onto documented 2026 infrastructure engineering patterns, and each one represents a specific architectural moment where Vizier's catalog-backed orchestration model delivers a structurally distinct answer.

Platform Engineering and the IDP Self-Service Problem

Teams building Internal Developer Platforms face a recurring failure mode: the platform team becomes the bottleneck because raw IaC authorship requires specialist knowledge that application developers do not have and should not need. The canonical solution is a curated catalog of trusted infrastructure primitives that developers can invoke without understanding the underlying HCL or YAML. Vizier's verified module catalog, combined with its orchestrated execution layer, maps precisely onto this pattern. The catalog provides the primitives; the orchestrator provides the guardrails that prevent developers from composing modules in ways that produce misconfigured or insecure infrastructure. Platform teams retain control over the catalog without having to manually review every provisioning request.

OpenTofu Migration Without Module Rewrites

For teams currently navigating the post-BSL transition, the practical question is not whether to migrate but how to do so without rewriting the module library accumulated over years of Terraform investment. Vizier treats OpenTofu as a first-class provisioning engine, which means the orchestration layer absorbs the engine substitution. Existing HCL modules continue to run unchanged; the migration surfaces at the orchestration layer rather than propagating into every module definition across the repository. This is architecturally significant because it decouples the license decision from the engineering effort, allowing teams to move on their own timeline without a module rewrite sprint blocking the transition.

Day-2 Operations as a Continuous Lifecycle

The industry framing of IaC as a one-time provisioning act has given way to a continuous operations model, where the same toolchain that provisions infrastructure is also responsible for configuration management, patch workflows, and state reconciliation over the full infrastructure lifetime. Vizier's coordination of Terraform and Ansible within a single orchestration framework directly addresses this. Terraform handles resource provisioning and state; Ansible handles configuration drift, patch application, and operational workflows on running infrastructure. The orchestrator maintains coherence between both layers so that Day-2 operations are not a separate manual process but a scheduled, auditable execution against the same verified module graph used for initial provisioning.

AI-Assisted Infrastructure Requires a Verified Module Graph

AI-powered infrastructure management is one of the defining 2026 trends, but AI tooling applied to unstructured or undocumented IaC repositories produces unreliable recommendations and hallucinated resource configurations. The prerequisite for reliable AI-assisted infrastructure generation is a structured, verified module graph with known inputs, outputs, and dependency relationships. Vizier's catalog, composed of statically validated and cosign-signed modules, provides exactly that substrate. Each module has a deterministic interface that AI tooling can reason over without inventing configuration parameters that do not exist in the actual provider schema.

Consolidating the Terragrunt, Ansible Tower, and CI Script Stack

Many production IaC environments in 2026 are held together by a combination of Terragrunt for DRY module composition, Ansible Tower or AWX for configuration workflows, and custom CI pipeline scripts that bridge the gap between the two. This architecture works until it does not, and the failure modes are well-known: state drift between the provisioning and configuration layers, pipeline scripts that encode tribal knowledge, and no unified audit trail across the full lifecycle. Vizier consolidates this into a single orchestrated execution model backed by commercially verified modules, eliminating the custom glue code and replacing it with a supported, structured abstraction that covers provisioning through ongoing configuration management without requiring a bespoke integration layer to hold it together.

Conclusion: What to Do With This Information

The IaC fragmentation problem documented throughout this analysis is structural, not incidental. Five distinct operational layers, a post-BSL ecosystem reshuffle still reverberating through platform teams in 2026, and persistent Day-2 gaps between Terraform provisioning and Ansible configuration management are not challenges you solve by adding another shell script or another wrapper tool. They require coordinated orchestration backed by verified, trustworthy primitives.

Vizier's defensible position is the combination that no open-source alternative currently replicates: catalog-backed orchestration, cosign-signed supply-chain security, unified Terraform/OpenTofu/Ansible execution, and per-module economics that eliminate subscription overhead entirely.

The actionable path forward is concrete. Audit your current IaC stack against the five operational layers. Identify whether your module sourcing carries any supply-chain security guarantees today; for most teams, the honest answer is no. Evaluate whether IaC Bazaar's catalog covers the infrastructure primitives your team depends on most frequently across AWS, EKS, and GKE environments.

Browse IaC Bazaar's verified module catalog and curated production-ready stacks as a direct starting point. Individual modules begin at $29 with no subscription required.