Docker Compose

Every feature, in the format's own order: whether every VM target can do it, whether Isoloom produces it, and how (or why not). See the overview for the rule.

Docker Compose

65% of 55 portable features (32 done, 8 partly, 15 to do; 118 features in all). From the compose-spec schema, commit 914ec15d1fa4 (crates/isoloom-core/coverage/compose-spec.json).

Top level

Key	Every target	Implemented	Notes
`version`	n/a	No	Obsolete in Compose
`name`	Yes	Yes	From `name`
`include`	n/a	No	Compose tooling, not the environment's behavior
`services`	Yes	Yes	From `machines`
`networks`	Yes	Yes	From `networks`
`volumes`	Yes	Yes	From `machines.*.volumes`
`secrets`	Yes	Another way	Via inputs (values given at launch, never baked into images)
`configs`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning
`models`	n/a	No	Compose tooling, not the environment's behavior
`jobs`	Yes	Another way	Via docker.init (one-shot jobs)

Services

Key	Every target	Implemented	Notes
`annotations`	n/a	No	Compose tooling, not the environment's behavior
`attach`	n/a	No	Compose tooling, not the environment's behavior
`blkio_config`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`build`	Yes	Yes	From `machines.*.docker.build`
`cap_add`	Yes	Partly	From `networks.*.gateway`; not yet: nothing more: capabilities only exist for containers (root on a VM has them all)
`cap_drop`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`cgroup`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`cgroup_parent`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`command`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning
`configs`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning
`container_name`	Yes	Another way	Via the machine's name
`cpu_count`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_percent`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_period`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_quota`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_rt_period`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_rt_runtime`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpu_shares`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`cpus`	Yes	Another way	Via machines.*.resources.cpus, written as deploy.resources.limits
`cpuset`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`credential_spec`	No	No	Windows containers only
`depends_on`	Yes	Yes	From `machines.*.depends_on`
`deploy`	Yes	Partly	From `machines.*.resources`; not yet: replicas (see `scale`)
`develop`	n/a	No	Compose tooling, not the environment's behavior
`device_cgroup_rules`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`devices`	No	No	Host devices: hosting services and cloud VMs have none to pass
`dns`	Yes	Not yet	DNS servers for a network or a machine
`dns_opt`	Yes	Not yet	With DNS
`dns_search`	Yes	Not yet	With DNS (search domains)
`domainname`	Yes	Not yet	With DNS (a domain for the environment)
`entrypoint`	Yes	Partly	Isoloom's own containers and init jobs; not yet: a machine's own: set it in its image
`env_file`	Yes	Another way	Via inputs
`environment`	Yes	Partly	From `machines.*.inputs`; not yet: fixed values: set them in the image or the provisioning
`expose`	Yes	Another way	Via machines.*.services (every port is reachable on the machine's networks)
`extends`	n/a	No	Compose tooling, not the environment's behavior
`external_links`	n/a	No	Legacy; replaced by networks
`extra_hosts`	Yes	Yes	From `machines.*.networks` (names of machines on other networks)
`gpus`	No	No	Local VMs can't use the host's GPU
`group_add`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning
`healthcheck`	Yes	Yes	From `machines.*.services` (a probe of every port)
`hostname`	Yes	Yes	From the machine's name
`image`	Yes	Yes	From `machines.*.docker.image`
`init`	n/a	No	Container mechanics: a VM always runs its own init
`ipc`	No	No	Shares a kernel namespace with the host or another machine: separate VMs can't
`isolation`	No	No	Windows containers only
`label_file`	n/a	No	Compose tooling, not the environment's behavior
`labels`	n/a	No	Compose tooling, not the environment's behavior
`links`	n/a	No	Legacy; replaced by networks
`logging`	n/a	No	Where the runner collects logs
`mac_address`	No	No	Cloud VMs get their MAC address from the provider
`mem_limit`	Yes	Another way	Via machines.*.resources.memory_mb, written as deploy.resources.limits
`mem_reservation`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`mem_swappiness`	No	No	Cloud VMs only choose a size: no CPU or memory scheduling knobs
`memswap_limit`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`models`	n/a	No	Compose tooling, not the environment's behavior
`network_mode`	Yes	Partly	Isoloom's own sidecars and check runner; not yet: nothing more: sharing another machine's network isn't possible between VMs
`networks`	Yes	Yes	From `machines.*.networks` (fixed addresses)
`oom_kill_disable`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`oom_score_adj`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`pid`	No	No	Shares a kernel namespace with the host or another machine: separate VMs can't
`pids_limit`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`platform`	Yes	Not yet	A CPU architecture (amd64, arm64): images, boxes and instance types all have one
`ports`	Yes	Yes	From `machines.*.services[].publish` (on the host's loopback)
`post_start`	Yes	Another way	Via machines.*.docker.init (runs once the machine answers)
`pre_start`	Yes	Another way	Via machines.*.depends_on and docker.init
`pre_stop`	n/a	No	Compose tooling, not the environment's behavior
`privileged`	Yes	Not yet	What it's for, as a machine feature: running containers or VMs inside, loading kernel modules (Isoloom then makes the container privileged)
`profiles`	Yes	Yes	From `checks` (a `check` profile)
`provider`	n/a	No	Compose tooling, not the environment's behavior
`pull_policy`	n/a	No	Compose tooling, not the environment's behavior
`pull_refresh_after`	n/a	No	Compose tooling, not the environment's behavior
`read_only`	Yes	Not yet	A read-only root filesystem (VMs can mount it read-only too)
`restart`	Yes	Yes	Always unless-stopped: machines stay up like VMs
`runtime`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`scale`	Yes	Not yet	Several identical machines (replicas), each with its own address
`secrets`	Yes	Another way	Via machines.*.inputs
`security_opt`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`shm_size`	Yes	Not yet	The size of /dev/shm (a mount option on VMs)
`stdin_open`	n/a	No	Compose tooling, not the environment's behavior
`stop_grace_period`	n/a	No	Compose tooling, not the environment's behavior
`stop_signal`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning
`storage_opt`	n/a	No	Container mechanics: a VM has none; Isoloom sets them itself when a machine needs them
`sysctls`	Yes	Partly	From `networks..gateway`; not yet: a machine's own network sysctls (net.): containers only allow those, VMs allow them too
`tmpfs`	Yes	Not yet	Memory-backed mounts (tmpfs works on VMs too)
`tty`	n/a	No	Compose tooling, not the environment's behavior
`ulimits`	Yes	Not yet	Process limits (limits.conf or systemd on VMs)
`use_api_socket`	No	No	Hands the host's Docker to a machine: VMs and the cloud have none
`user`	Yes	Partly	Isoloom's check runner, as root to drop its default route on offline networks; not yet: a machine's own user: set it in its image
`userns_mode`	No	No	Shares a kernel namespace with the host or another machine: separate VMs can't
`uts`	No	No	Shares a kernel namespace with the host or another machine: separate VMs can't
`volumes`	Yes	Partly	From `machines.*.volumes` (and read-only mounts of init and check scripts); not yet: data shared between machines
`volumes_from`	Yes	Not yet	With volumes (data shared between machines)
`working_dir`	Yes	In the image	Set it in the image (`docker.build`) or the VM's provisioning

Networks

Key	Every target	Implemented	Notes
`attachable`	n/a	No	Compose tooling, not the environment's behavior
`driver`	No	No	Docker network drivers (overlay, macvlan) have no VM equivalent
`driver_opts`	No	No	Docker network driver options
`enable_ipv4`	n/a	No	Networks are IPv4 (the default)
`enable_ipv6`	Yes	Not yet	IPv6 networks
`external`	Yes	Not yet	Joining a network outside the environment (a Docker network, a host bridge, a VPC)
`internal`	Yes	Yes	From `networks.*.internet: false` (when nothing routes)
`ipam`	Yes	Yes	From `networks.*.cidr`
`labels`	n/a	No	Compose tooling, not the environment's behavior
`name`	n/a	No	Compose scopes names to the environment

Volumes

Key	Every target	Implemented	Notes
`driver`	No	No	Docker volume drivers have no VM equivalent
`driver_opts`	No	No	Docker volume driver options
`external`	Yes	Not yet	With volumes (data that outlives the environment)
`labels`	n/a	No	Compose tooling, not the environment's behavior
`name`	n/a	No	Compose scopes names to the environment