Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Core Concepts

To get the most out of BinaryCircuits, it helps to understand a few core ideas about how workflows are structured, how they run, and how they are managed once compiled.

This chapter deliberately focuses on what you work with, not how it is implemented internally.

Workflows

A workflow is the highest‑level container for your automation. It represents a complete, end‑to‑end process, such as:

  • “Fetch new emails and post them to Slack.”
  • “Process new customer sign‑ups and add them to the CRM.”
  • “Run a daily AI report over yesterday’s sales.”

When you acquire a compiled binary from the BinaryCircuits marketplace, you are getting a single, executable workflow that encapsulates all of the nodes, connections, and logic from its original n8n design.

Workflow Identity & Versions

Every workflow in the marketplace has:

  • A human‑friendly name (for example, “AI Email Classifier”).
  • A unique identifier that the platform uses behind the scenes.
  • A version, so that improvements and bug fixes can be shipped without breaking existing deployments.

When you download or compile a workflow, the binary you receive corresponds to a specific version. You can continue to run that version as long as you like, even if newer versions are later published.

If a new version introduces features or fixes you want, you you would typically re-download or re-compile that updated version via the BinaryCircuits app and then deploy it in place of the old one.

Nodes

A node is a single building block within a workflow. Each node performs one specific action. Workflows are created by connecting multiple nodes together to form a sequence of operations.

Here are a few examples of nodes:

  • Read IMAP: Fetches emails from an email server.
  • HTTP Request: Makes a request to an external API.
  • Slack: Sends a message to a Slack channel.
  • Code: Executes a small piece of custom JavaScript or Python code.
  • Set: Creates or modifies data within the workflow’s memory.

When a workflow runs, data flows from one node to the next, with each node performing its action on the data it receives. The compiled binary takes care of orchestrating that flow; as a user, you do not need to manage individual nodes directly.

Inputs and Outputs

Each workflow exposes a logical input and logical output:

  • The input is the JSON data you provide when starting a run (for example, { "user_id": 123 }).
  • The output is the JSON data the workflow emits when it finishes (for example, a processed record, a summary, or a status object).

The expected inputs and outputs for any given workflow are typically detailed in its marketplace description or when inspecting the workflow within the BinaryCircuits application. Internally, nodes may have many intermediate inputs/outputs, but as a user you usually only need to care about the “entry” and “exit” of the workflow as a whole.

Triggers

A trigger is a special type of node that starts a workflow. It’s the entry point for the entire process. Common trigger types include:

  • Manual Trigger: The workflow starts only when you explicitly run it (for example, by running the binary in the terminal or pressing a key in the controller UI). This is the default for most compiled workflows.
  • Webhook Trigger: The workflow starts when an external service sends an HTTP request to a specific URL. With the BinaryCircuits Controller, the controller exposes this URL and starts the appropriate workflow binary when a request is received. This is used to integrate with services that support webhooks (like GitHub, Stripe, or Twilio).
  • Cron (Scheduled) Trigger: The workflow runs automatically on a predefined schedule (for example, every hour, or every Monday at 9 AM).

When you use the BinaryCircuits Controller, it is responsible for listening for these trigger events (such as webhook calls or scheduled times) and starting the appropriate workflow binary with the correct input.

Manual vs Automated Runs

  • Manual runs are ideal while you are testing and validating a workflow. You start runs by hand and inspect the output.
  • Automated runs are ideal once a workflow is stable and you want it to react to external events or time‑based schedules without human intervention.

You can start with manual runs and later connect the same workflow to webhooks or schedules via the controller without re‑writing it.

The Marketplace

The BinaryCircuits marketplace is where you discover, acquire, and manage workflows.

From a user perspective, the marketplace, typically accessed via the BinaryCircuits TUI/CLI app, gives you:

  • A catalogue of workflows organised by category (AI, DevOps, Finance, CRM, etc.).
  • Clear pricing per workflow (for one‑time purchases) and per subscription tier.
  • Information about what each workflow does, what it needs as input, and what it returns.
  • Ratings and metadata that help you decide whether a workflow is suitable for your use case.

Your subscription tier determines which workflows you can access without extra payment, and you can always purchase individual high‑value workflows separately if you prefer a one‑off model.

The Controller

The controller is an optional but powerful part of BinaryCircuits. It is a long‑running service that:

  • Keeps track of which compiled workflow binaries are available on a machine.
  • Starts these compiled workflows in response to triggers (manual, HTTP, cron).
  • Records basic information about each run (status, timing, often minimal logs).

You can think of it as the “automation host”:

  • Workflows themselves are compact, self‑contained binaries.
  • The controller is the system that knows when and why to run them.

You can run workflows without the controller (by executing the binaries directly), but using the controller makes it much easier to manage more than a couple of workflows in production.

Your Account, Tiers, and Limits

Your BinaryCircuits account ties together:

  • Your subscription tier (Free, Hobbyist, Pro, Business, Enterprise).
  • Your entitlement to workflows in the marketplace.
  • Your compilation or download quotas where applicable.

Key points:

  • Free users can experiment with a generous selection of workflows and a limited number of compilations per month.
  • Paid tiers increase both access (more workflows, higher‑value categories) and capacity (more compilations, better support).
  • Compiled binaries you create or download remain usable even if you change or cancel your subscription; the quotas apply to new compilations or downloads.

The Pricing & Subscriptions chapter goes into these details, but conceptually it’s helpful to remember:

Your subscription controls what you can access and how much you can compile or download, not whether already‑compiled binaries continue to run.

Putting It All Together

From a user’s perspective, the BinaryCircuits “mental model” looks like this:

  1. You browse the marketplace for a workflow that solves your problem.
  2. Your account and subscription determine whether you can access it freely or need to purchase it.
  3. You download or compile the workflow binary.
  4. You run it either:
    • Directly from the command line, or
    • Via the controller, which handles triggers, scheduling, and monitoring.

You never need to interact with the underlying codebase or internal services to benefit from this model; those are intentionally hidden behind a simple, predictable user experience.