Skip to main content
A plugin is an integration type, such as Snowflake or dbt. A connection is one instance of it. One plugin usually manages several connections. A single Snowflake plugin can hold prod, dev, and analytics connections at once, and each dbt project root is its own connection. A connection is identified by its plugin and its handle, so the same connection cannot be added twice.

​
Available plugins

Each plugin uses its own system’s setup. Alkera renders the form; nothing about it is particular to Alkera. Generic SQL connects to any SQL database with a SQLAlchemy URL.
Plugins for dashboards and analytics tools are coming soon.
Curious about an integration we do not support? Email contact@alkera.ai. We would love to hear what you want to connect, and it may already be on our roadmap.

​
What a plugin can do

Each connection declares its capabilities, and Alkera’s tools are built on top of them. A warehouse connection that can run SQL, introspect schema, and estimate cost lights up the query and schema tools with no extra work.

​
Adding a connection

Alkera keeps a feed of suggested connections: candidates it already knows about, waiting for you to add. A suggestion comes from one of two places.

​
Preconfigured by your team

An admin set the connection up once for the whole team. Preconfigured connections come with the shared setup already filled in, so you never handle a shared secret. You may still finish your part, such as signing in via OAuth or supplying a detail specific to you, before the connection is ready.

​
Detected in your workspace

Alkera looks for signs of a data source as you work and offers what it finds. It watches for:
  • Environment variables, such as warehouse credentials already set in your shell.
  • Files in your project, such as a dbt project (dbt_project.yml), a local DuckDB or SQLite file, or a connection profile. It can even find connections through credentials configured within dbt and Apache Airflow.
  • Keychain entries for a known provider.
Each suggestion shows where it came from, so you know why it is being offered.

​
Detecting is not adding

Local, offline sources are added for you. DuckDB files, dbt projects, and SQLite files activate on detection, because they carry no remote credentials and no production risk. Everything else waits as a suggestion until you add it yourself, so you never point the agent at production by accident. To add or configure a connection, open the Plugins & Connections manager: /plugins in the CLI, or the Plugins & Connections page in your IDE.

​
Authentication

Alkera connects to your systems as you. Whatever roles and grants your warehouse already enforces continue to apply, unchanged. An admin can also set a connection up once for the whole team with preconfigured connections, so members connect without ever directly handling the shared secret.
BigQuery Plugin. Sign in before you add the connection: run gcloud auth application-default login. Alkera resolves a token from your existing credentials at connection time.

​
Credentials

Alkera stores a reference to your secret, never the secret. The reference points at one of three places on your machine:
  • An environment variable
  • A file, created with owner-only permissions
  • Your operating system keychain
The secret is resolved at the moment a connection opens, inside the connector. It never enters the agent’s context, and it is never written to your project.

​
Scope and control

Connections belong to a project, not to your account. They live in that project’s .alkera/ directory, so a different project starts clean. Plugins are on by default and provide tools, lineage, and context when connections of their type are added.

Agent & Tools

Permission modes, effects, and how the agent uses lineage.