Network access
A task has no network until you ask for it. Set execution.network in task.yaml to let it call out, or to serve requests.
1 · Allow outbound hosts
Set type: egress and list the hosts the task may reach; leave the list out to allow all hosts, or write [] to allow none.
execution:
network:
type: egress # none (default) | egress | bidirectional
egress_allow:
- api.github.com
- "*.s3.amazonaws.com" # a left-most * is the only wildcard2 · Check it offline
task:validate refuses a network block that does not fit together before you deploy.
$ ignitify task:validate fetch✓ task config valid
3 · Reach an allowed host
A call to a host on the list works.
$ ignitify task:run fetch --payload '{"url":"https://api.github.com"}' --wait✓ Run COMPLETED · 9sRun Detailsstatus COMPLETEDResult: { "url": "https://api.github.com", "status": 200 }
4 · See a blocked host
A call to any other host is cut off, and the task sees a reset connection.
$ ignitify task:run fetch --payload '{"url":"https://example.com"}' --wait✓ Run COMPLETED · 12sRun Detailsstatus COMPLETEDResult: { "url": "https://example.com", "error": "Error: read ECONNRESET" }
5 · Serve requests
Use type: bidirectional with the port the task listens on and the paths you open, because a path you do not list is refused.
execution:
network:
type: bidirectional
inbound_port: 8080 # required; the task calls ctx.ready() once it listens
inbound_routes:
- prefix: /webhooks/
- path: /health6 · Choose what a second run does
A bidirectional task runs one VM at a time, and --on-busy picks whether a second run waits (queue, the default) or fails at once (reject).
$ ignitify task:run listen --on-busy reject✗ Run refused — this bidirectional deployment already has a live VM. Concurrent VMs for bidirectional-network tasks are not supported (one VM at a time). Retry when the live VM finishes, or omit --on-busy=reject to queue instead.server trace id: 019fdec6-5c20-7a14-b8d3-0f7e2c91a4b6