Bluelink Documentation

website·Indexed 30 days ago

https://bluelink.dev

Documentation for Bluelink, featuring the Deploy Engine HTTP API v1, Blueprint Framework, and Plugin Framework. Includes guides on authentication using API Keys, JWTs, and Bluelink Signature v1, as well as specifications for registry protocols, service discovery, and plugin archive structures.

Tokens
50.3K
Snippets
224
Records
335
Agent score
49%

What's inside Bluelink

  1. Overview of Bluelink installation options

    Bluelink can be installed using three different methods depending on the user's needs:

    1. Easy Install (Recommended): A streamlined process using a one-line installer script or a Windows installer.
    2. Bluelink Manager: A cross-platform CLI tool used to install, update, and manage specific Bluelink components.
    3. Manual Installation: Downloading and configuring each component individually.

    Bluelink also supports profiles for different toolchains. The default is the Bluelink profile, but a Celerity profile is also available.

  2. Overview of the Bluelink Deploy Engine

    The Deploy Engine is the core component of Bluelink responsible for validating and deploying blueprints (which define Bluelink applications, similar to AWS SAM templates). It handles extensive blueprint validation, change staging, resource deployment, and resource destruction. It powers the Bluelink CLI and exposes an HTTP API for third-party tool integration.
  3. Overview of the Bluelink Registry Protocol

    The Registry Protocol is used by the Bluelink CLI to discover and install plugins. While the official implementation is hosted at registry.bluelink.dev, developers can implement custom registries to host private organizational plugins. Note that the public registry includes additional UI-specific functionality not covered by this protocol and should not be replicated in custom implementations as those interfaces may change.
  4. Overview of the Blueprint Specification v2025-11-02

    The Blueprint Specification is a resource-agnostic framework used to define bundles of resources (e.g., Cloud services, REST APIs, Docker containers) as a logical deployable unit. It simplifies resource relationships by using labels, link selectors, and annotations, abstracting the underlying complexity of networking and permissions. Blueprints can be authored in three formats: the Blueprint Language, JWCC (JSON with Commas and Comments, typically using the .jsonc extension), or YAML.
  5. Overview of the Blueprint Language

    The Blueprint Language is a first-class configuration language tailored for the Bluelink blueprint model. It is semantically equivalent to YAML and JWCC formats, mapping to the same canonical schema. Unlike YAML and JWCC, which embed substitution logic in ${..} strings, the Blueprint Language treats expressions (references, function calls, and infix operators) as first-class elements that do not require substitution wrappers.
  6. Overview of the Bluelink Plugin Framework

    The Plugin Framework extends the Deploy Engine's functionality using blueprint resources, data sources, and functions. It categorizes plugins into two primary types:

    • Providers: Provide elements used within blueprints (e.g., resource types).
    • Transformers: Apply transformations to blueprints.
  7. Overview of Bluelink authentication mechanisms

    Bluelink components and public HTTP APIs (such as the Deploy Engine) support several authentication methods to secure requests. These include standard industry tokens and a specialized signature mechanism to avoid transmitting private keys over the network.
  8. Overview of Bluelink infrastructure management

    Bluelink is an infrastructure tool that allows developers to define resources and their connections (links) rather than manually writing the underlying "plumbing." It automatically generates the necessary IAM, networking, and security configurations based on industry best practices. Key features include:

    • Relationship-based configuration: Derive networking and permissions from declared resource connections.
    • Custom Primitives: Use transformers to define high-level building blocks on top of raw cloud resources.
    • Developer Tooling: Includes a CLI and an editor language server providing autocomplete, validation, and documentation based on the project's specific providers and transformers.
  9. Understand Blueprint Framework error types

    The Blueprint Framework uses specific Go error types to categorize failures during different stages of the lifecycle:

    • Validation Errors: Occur when the framework cannot load a blueprint document. These are typically returned as errors.LoadError (file system errors, malformed documents, or specification violations) or errors.RunError (configuration issues, missing element types, or missing plugins, such as using an aws/lambda/function resource without the aws plugin installed).
    • Deployment Errors: Occur during the deployment or destruction of a loaded blueprint instance. Most of these are returned as errors.RunError, though some may be plain Go errors.
  10. Get Bluelink CLI help and version information

    Access general help, command-specific usage, or the current CLI build version (including OS, architecture, and build date).
    # General help
    bluelink help
    
    # Help for a specific command
    bluelink [command] --help
    
    # Print CLI version and build details
    bluelink version
  11. Understand Bluelink v1 (Preview) capabilities and multi-cloud support

    Bluelink v1 (Target Release: October 2027) expands the ecosystem to full multi-cloud capabilities. Key additions and changes include:

    • Multi-Cloud Providers: Full support for AWS, Azure, and Google Cloud providers, focusing on core services required for Celerity v1.
    • Enhanced Celerity Transformer: Supports transforming Celerity application resources into concrete resources across AWS, Azure, and Google Cloud.
    • Core Components: Maintains the Bluelink CLI, Deploy Engine, Plugin Framework, and Blueprint Language Server.