dfx.json configuration options
Overview
Every project created and deployed with dfx
requires a dfx.json
file to be present in the project's root directory. The dfx.json
file configures the project's settings such as the canisters in the project, their name, type, and source file, default project build settings, and other configuration parameters such as Wasm optimizations. This page will detail some of the most common configuration options. For a full list of the possible configuration settings in dfx.json
, view the dfx.json
schema.
Default dfx.json
file
By default, when a project is created with dfx new <project-name>
, and the options Motoko
and No frontend canister
are selected, the default dfx.json
generated for the project will contain the following:
{
"canisters": {
"example_backend": {
"main": "src/example_backend/main.mo",
"type": "motoko"
}
},
"defaults": {
"build": {
"args": "",
"packtool": ""
}
},
"output_env_file": ".env",
"version": 1
}%
This configuration contains the following components:
canisters
: Defines the canister names and settings for the project. In this default example, a single canister calledexample_backend
is defined.example_backend
: Defines the name of the canister in this project.main
: The primary source code file for the canister that serves as the canister's entrypoint. By default, for Motoko canisters this file ismain.mo
. For Rust canisters,type
: Defines the type of the canister. Supported types aremotoko
,rust
,assets
,pull
andcustom
. The Motoko and Rust languages are supported through the IC SDK by default.custom
type refers to canisters written in languages other than Motoko or Rust.defaults
: Default settings for the project's build.build
: Build process configuration.args
: Arguments for thepacktool
setting.packtool
: Configures a package management tool for your canister's dependencies. Examples includemops
andvessel
for Motoko.output_env_file
: Environment variables will be written to this file without overwriting any user-defined variables if the file already exists.version
: Refers to the iteration version for thisdfx.json
file. By default, versions ofdfx.json
start atversion: 1
.
Custom canister definitions
To define a canister to use a language other than Motoko
or Rust
, or to use a custom Wasm file, you can set the canister as "type": "custom"
with the following additional arguments:
"canisters": {
"example_backend": {
"build": "npx azle example_backend",
"candid": "src/example_backend/example_backend.did",
"gzip": true,
"main": "src/example_backend/src/index.ts",
"type": "custom",
"wasm": ".azle/example_backend/example_backend.wasm"
}
}
build
: The command that will build the canister.candid
: The file path to the canister's Candid interface definition file.gzip
:true
orfalse
if Wasm gzip should be used.main
: The primary source code file for the canister that serves as the canister's entrypoint.type
: Defines the canister ascustom
.wasm
: The file path to the canister's Wasm file.
Asset canisters
An asset canister is a type of canister that contains a project's frontend user interface and asset files. For projects created with dfx new <projectname>
command with 'Vanilla JS' chosen as the frontend framework, the project's dfx.json
file will contain the following asset canister definition:
"canisters": {
"example_frontend": {
"dependencies": [
"example_backend"
],
"source": [
"src/example_frontend/dist"
],
"type": "assets",
"workspace": "example_frontend"
}
},
dependencies
: Defines what canister the asset canister is dependent on to communicate with.source
: The project directory containing the asset canister's source files.type
: Defines the canister as typeassets
.workspace
: The project directory containing this canister'spackage.json
file.
Pullable canisters
Canisters that provide a public service at a static canister ID can be pulled into your project by defining "type": "pull"
. This indicates that the canister's Wasm and Candid file will be pulled from the specified canister ID on the mainnet.
Below is an example project that defines three canisters: dapp
, which is dependent on dep_b
and deb_c
, both of which are pullable canisters:
{
"canisters": {
"dapp": {
"type": "motoko",
"main": "src/main.mo",
"dependencies": [
"dep_b", "dep_c"
]
},
"dep_b": {
"type": "pull",
"id": "yhgn4-myaaa-aaaaa-aabta-cai"
},
"dep_c": {
"type": "pull",
"id": "yahli-baaaa-aaaaa-aabtq-cai"
}
}
}
type
: Defines the canister as typepull
, meaning the canister's Wasm and Candid files will be retrieved from the mainnet.id
: Specifies the canister's ID on the mainnet that should be used to obtain the Wasm and Candid files.
Network settings
Local development network settings can be configured in dfx.json
, such as:
"networks": {
"dev": {
"providers": [
"https://ic0.app"
],
"type": "persistent"
}
}
Network definitions can have the following configuration components:
providers
: Defines the network provider, which can be localhost or any other domain name. Domain names must be a full URL, such ashttps://domain.com
.type
: Defines the network type, which can be either ephemeral (do not retain same canister IDs) or persistent (retain the same canister IDs).
Learn more about custom network definitions and configurations.
Wasm optimization options
Canisters can be optimized using wasm-opt
, which exposes a few different optimization options using the optimize
configuration:
{
"canisters": {
"my_canister": {
"optimize": "cycles"
}
}
}
optimize
: Possible values arecycles
andsize
. The valuecycles
optimizes your canister at alevel 3
inwasm-opt
, which is the recommended default value.size
provides an aggressive optimization of the binary size. Learn more in thewasm-opt
documentation.
Further reading
There are several workflow-specific dfx.json
configuration options detailed in the full dfx.json
schema.