Configuration: malloy-config.json

VSCode

Both the VS Code Extension and the Malloy CLI use a malloy-config.json file to configure database connections. This page documents the shared file format, connection types, and environment variable options.

Config File Format

The file contains a connections object where each key is a connection name and each value specifies the connection type and its parameters. The first connection listed is the default.

{
  "connections": {
    "my_duckdb": {
      "is": "duckdb",
      "databasePath": "./data.db"
    },
    "my_bq": {
      "is": "bigquery",
      "projectId": "my-project"
    }
  }
}

The is field identifies the connection type. All other fields are type-specific parameters documented below.

Default connections

Setting includeDefaultConnections to true automatically creates a connection for every registered database type that you haven't already listed. Each gets the type's name as its connection name and picks up any registered property defaults:

{
  "includeDefaultConnections": true,
  "connections": {
    "warehouse": {
      "is": "duckdb",
      "databasePath": "./data.db"
    }
  }
}

In this example, you get your explicit warehouse connection plus auto-generated connections for bigquery, postgres, snowflake, etc. — each with default settings. A generated connection is skipped if its type or name collides with one you already listed.

Config file discovery

Both VS Code and the CLI discover config files automatically. Starting from the Malloy file you're working with, Malloy walks up through parent directories until it reaches the project root, looking for malloy-config.json at each level. The first one found is used.

You can also place a malloy-config-local.json alongside malloy-config.json for developer-specific overrides (credentials, local paths) that shouldn't be checked into git. When both files exist at the same directory level, they are merged: connections entries are deep-merged by name (local wins on conflicts), while all other sections (manifestPath, includeDefaultConnections, etc.) are replaced wholesale by the local file's value.

Add malloy-config-local.json to your .gitignore:

malloy-config-local.json

Connection Types

duckdb — DuckDB / MotherDuck

Restricted execution

For untrusted code, Malloy offers a single securityPolicy property with three levels:

• "none" — no security policy applied. Ordinary DuckDB behavior. This is the default.

• "local" — no network access. DuckDB cannot reach the network, but local filesystem access is not sandboxed to specific directories. Appropriate when the host already provides filesystem isolation (e.g. a container boundary).

• "sandboxed" — no network access AND filesystem confined to allowedDirectories (defaults to workingDirectory). The reviewed strict recipe for untrusted Malloy. POSIX only.

Both "local" and "sandboxed" force enableExternalAccess=false, block httpfs and INSTALL, reject remote databasePath and motherDuckToken, lock configuration, and encrypt temp files. "sandboxed" additionally enforces directory containment and derives a safe tempDirectory inside the sandbox.

DuckDB's enable_external_access is a single toggle that gates both filesystem reach and network reach. allowed_directories only takes effect when external access is disabled. This is why securityPolicy is a single axis — the underlying DuckDB mechanism does not support independent filesystem and network control.

The reviewed strict recipe:

{
  "connections": {
    "duckdb": {
      "is": "duckdb",
      "databasePath": "data/app.duckdb",
      "workingDirectory": {"config": "rootDirectory"},
      "securityPolicy": "sandboxed"
    }
  }
}

Policies set a floor, not a ceiling. allowedDirectories and tempDirectory can be set explicitly to customize the sandbox. Other policy-controlled settings accept matching values but reject weaker ones — connection creation fails closed. setupSQL, additionalExtensions, motherDuckToken, and remote databasePath are incompatible with any restricted policy; to use them, keep securityPolicy at "none" and configure DuckDB directly. Policies do not set resource limits — configure threads, memoryLimit, timeouts, and host quotas separately.

bigquery — Google BigQuery

databricks — Databricks

Authentication: provide either token or the oauthClientId + oauthClientSecret pair.

postgres — PostgreSQL

mysql — MySQL

snowflake — Snowflake

Snowflake also supports TOML configuration at ~/.snowflake/connections.toml. See Snowflake connection configuration for details.

trino — Trino

The ssl, session, extraCredential, and extraHeaders properties accept JSON objects that are passed directly to the underlying trino-client library. For example, to connect to a Trino server with a self-signed certificate:

{
  "connections": {
    "my_trino": {
      "is": "trino",
      "server": "https://trino.example.com",
      "catalog": "hive",
      "user": "analyst",
      "password": {"env": "TRINO_PASSWORD"},
      "ssl": {"rejectUnauthorized": false}
    }
  }
}

Because these properties use the json type, {"env": "..."} inside them is treated as literal data, not as an environment variable reference.

presto — Presto

Setup SQL

All connection types support a setupSQL parameter. This is a multi-line text field containing SQL statements to execute each time the connection is established.

Each statement must end with ; at the end of a line. Statements can span multiple lines. Only one statement-ending ; is allowed per line.

Correct — each statement ends with ; on its own line:

SET search_path TO analytics;
CREATE TEMP TABLE foo
  AS SELECT 1;

Incorrect — two statements on the same line:

SET search_path TO analytics; CREATE TEMP TABLE foo AS SELECT 1;

Manifest Path

The config file can specify where persistence manifests are stored:

{
  "connections": { ... },
  "manifestPath": "MANIFESTS"
}

The manifestPath property is optional and defaults to "MANIFESTS". The manifest file is <manifestPath>/malloy-manifest.json, relative to the config file's location. Both the builder (malloy-cli build) and the VS Code extension read the manifest from this path.

Environment Variables

Any property value can be replaced with an environment variable reference. This is especially useful for sensitive values like passwords and API tokens, so they don't need to appear directly in your config file:

{
  "connections": {
    "my_motherduck": {
      "is": "duckdb",
      "databasePath": "md:my_database",
      "motherDuckToken": {"env": "MOTHERDUCK_TOKEN"}
    },
    "my_postgres": {
      "is": "postgres",
      "host": "db.example.com",
      "password": {"env": "PG_PASSWORD"}
    }
  }
}

The {"env": "VAR_NAME"} syntax looks up the value from the named environment variable at connection time. If the variable is not set, the field is omitted and the connection proceeds without it.

You can also provide a plain string value directly — this is useful for testing but not recommended for shared or committed config files.