Azure Functions
Floci-AZ emulates Azure Functions by spawning real Azure Functions runtime Docker containers on demand and proxying HTTP invocations to them.
Requirements
- Docker daemon reachable at
/var/run/docker.sock(bind-mounted into the floci-az container) - Internet access on first use to pull the runtime images
Supported Runtimes
| Runtime | Image |
|---|---|
node |
mcr.microsoft.com/azure-functions/node:4 |
python |
mcr.microsoft.com/azure-functions/python:4 |
java |
mcr.microsoft.com/azure-functions/java:4 |
dotnet |
mcr.microsoft.com/azure-functions/dotnet-isolated:4 |
Endpoint
Default account: devstoreaccount1
Management API
Apps
| Method | Path | Description |
|---|---|---|
PUT |
/admin/apps/{appName} |
Create or update a function app |
GET |
/admin/apps/{appName} |
Get a function app |
GET |
/admin/apps |
List all function apps |
DELETE |
/admin/apps/{appName} |
Delete a function app and all its functions |
Create app request body:
linuxFxVersion is optional. When set, floci-az selects the matching Azure Functions
Linux image, such as mcr.microsoft.com/azure-functions/python:4-python3.12.
The ARM-compatible Microsoft.Web/sites and Microsoft.Web/sites/{name}/config/web
paths accept the same setting under properties.siteConfig.linuxFxVersion and
properties.linuxFxVersion, respectively.
Functions
| Method | Path | Description |
|---|---|---|
PUT |
/admin/apps/{appName}/functions/{funcName} |
Deploy a function (ZIP upload) |
GET |
/admin/apps/{appName}/functions/{funcName} |
Get function details |
GET |
/admin/apps/{appName}/functions |
List functions in an app |
DELETE |
/admin/apps/{appName}/functions/{funcName} |
Delete a function |
Deploy function request body:
The ZIP must contain your function code in the Azure Functions v4 layout:
Invocation
| Method | Path | Description |
|---|---|---|
GET / POST |
/api/{appName}/{funcName}[?...] |
Invoke an HTTP-triggered function |
Warm Container Pool
By default, floci-az keeps function containers warm after first use (LIFO pool, one per function).
Containers are evicted after FLOCI_AZ_SERVICES_FUNCTIONS_CONTAINER_IDLE_TIMEOUT_SECONDS seconds of inactivity (default 300 s / 5 minutes).
To disable warm reuse and get a fresh container per invocation:
Mocked Mode
Set mocked: true (default false) to run the Functions service without Docker:
In mocked mode the management plane (create app, deploy/list/get/delete
function) works entirely from state and no runtime container is ever launched.
Because user code cannot execute without the runtime container, invocations
(POST api/{app}/{func}) return a synthetic 200 stub instead of running the
function. Useful for tests and CI environments without a Docker daemon.
| Environment Variable | Default | Description |
|---|---|---|
FLOCI_AZ_SERVICES_FUNCTIONS_MOCKED |
false |
Mocked mode (management plane only, no Docker; invocations return a synthetic 200 stub) |
Embedded DNS (Docker-in-Docker)
When floci-az is itself running inside Docker, it starts an embedded UDP/53 DNS server and
injects it into every spawned function container. This lets function containers resolve
custom hostnames (configured via floci-az.hostname or floci-az.dns.extra-suffixes) to
floci-az's Docker-network IP — useful when functions connect to Blob Storage using a
hostname-based endpoint rather than a raw IP.
On the host, no DNS setup is needed; the embedded server is a no-op.
Linux Native Docker — Firewall Note
On native Linux Docker (not Docker Desktop), function containers reach the host via
host.docker.internal (automatically mapped to host-gateway). If you run UFW with the
default INPUT DROP policy, invocations will time out. Fix:
This is not needed on Docker Desktop (macOS/Windows) or when floci-az runs inside Docker.