appliku.yml Configuration¶

The appliku.yml file is a YAML configuration file that defines how your application should be built, deployed, and configured in Appliku. Place this file in the root directory of your application repository.

To verify the configuration, go to the application settings page, "YAML Config" tab.

You can specify a different file for configuration, which is convenient for production/non-production environments running different sets of commands.

Example¶

You can check out an example in the SpeedPy boilerplate: appliku.yml

Root Level Structure¶

The configuration file contains the following top-level sections:

build_settings — Application build configuration
services — Application processes/services
databases — Database services
volumes — Persistent storage volumes
cronjobs — Scheduled tasks
commands — Saved commands for the Run Command tab

Build Settings¶

The build_settings section configures how your application is built and prepared for deployment.

Required Fields¶

build_image (string) — The buildpack or runtime environment to use

Optional Fields¶

build_command (string) — Command to run during the build phase
dockerfile (string) — Custom Dockerfile content (when using dockerfile or custom build_image)
dockerfile_path (string) — Path to Dockerfile in repository (default: "Dockerfile")
dockerfile_context_path (string) — Build context path for Dockerfile
container_port (integer) — Port your application listens on inside the container
skip_release_command (boolean) — Skip running release command after deployment (default: false)
expose_web_port (boolean) — Expose container port on all interfaces (default: false)
is_static_site (boolean) — Mark application as static site (default: false)
output_directory (string) — Directory containing built static files
environment_variables (array) — Environment variables for the application

Available Build Images¶

The default build image is python-3.14-uv-node-26. See Build Images for the tools in each image.

Python Runtimes: - python-3.15, python-3.14, python-3.13, python-3.12, python-3.11 - Legacy: python-3.10, python-3.9, python-3.8, python-3.7

Python + uv Runtimes: - python-3.15-uv, python-3.14-uv, python-3.13-uv, python-3.12-uv, python-3.11-uv

Python + Node.js Runtimes: - python-3.15-node-26, python-3.14-node-26, python-3.13-node-26, python-3.12-node-26, python-3.11-node-26 - Deprecated (Node.js end-of-life): python-3.14-node-25.6, python-3.13-node-20.18, python-3.12-node-20.10, python-3.11-node-20.10, python-3.10-node-20.10

Python + uv + Node.js Runtimes: - python-3.15-uv-node-26, python-3.14-uv-node-26, python-3.13-uv-node-26, python-3.12-uv-node-26 - Deprecated (Node.js end-of-life): python-3.14-uv-node-25.6, python-3.13-uv-node-25.6, python-3.12-uv-node-25.6, python-3.11-uv-node-25.6

Node.js Runtimes: - node-26-npm, node-26-yarn, node-24-npm, node-22-npm - Deprecated (Node.js end-of-life): node-25-npm, node-20-npm, node-20-yarn, node-14

Ruby Runtimes: - ruby-3.4.1, ruby-3.3-rails

Static Sites: - no-build-static — Static files without a build step (only with is_static_site: true)

Custom: - dockerfile — Use Dockerfile from codebase - custom — Custom Dockerfile entered in the dashboard

See Predefined Dockerfiles for the full Dockerfile contents of each build image.

Environment Variables¶

Environment variables can be configured in four ways:

1. Static Value:

environment_variables:
  - name: MY_ENV_VAR
    value: my_value

2. From Database (public connection):

environment_variables:
  - name: DATABASE_URL
    from_database:
      name: db
      property: connection_url

3. From Database (private/internal connection):

environment_variables:
  - name: DATABASE_URL
    from_database:
      name: db
      property: private_connection_url

4. From Domains:

Sets the variable to a comma-separated list of all domains added to the application, including the default .applikuapp.com subdomain if enabled.

environment_variables:
  - name: ALLOWED_HOSTS
    from_domains: true

5. Manual Configuration:

Documents that a variable is supposed to be set by the user. It will be present with an empty value in the list of environment variables in the dashboard.

environment_variables:
  - name: OPENAI_API_KEY
    source: manual

Services¶

The services section defines the processes that run your application. Each service is a key-value pair where the key is the service name and the value contains the service configuration.

Service Configuration Fields¶

command (string) — Command to run the service
scale (integer) — Number of instances to run (default: 1)
mode (string) — Service mode: replicated or global (default: "replicated")
placement_constraints (string) — Docker Swarm placement constraints
resources_limits_memory (string) — Memory limits (e.g., "512M", "2G")
resources_limits_cpus (string) — CPU limits (e.g., "0.5", "2")
resources_reservations_memory (string) — Memory reservations
resources_reservations_cpus (string) — CPU reservations
image — Use an existing image (e.g., from Docker Hub)
volumes — List of Docker volumes
shm_size — Shared memory size
ports — Port mappings between host and containers

There is no mem_limit key in appliku.yml. Use resources_limits_memory to set a memory limit. See Resource Limits.

See Docker Services Specification and Docker Deploy Specification for more details.

Example Services¶

services:
  web:
    command: gunicorn project.wsgi --log-file -
    scale: 1
    mode: replicated
    resources_limits_memory: 512M
    resources_limits_cpus: "0.5"

  worker:
    command: celery -A project worker -l info
    scale: 2
    mode: replicated

  release:
    command: bash release.sh

Resource Limits¶

The four resources_* keys set the CPU and memory limits and reservations of a service. A limit is the maximum that the container can use. A reservation is the amount that the container is expected to need: in a cluster, Docker Swarm uses it to select a node, and for memory it is a soft minimum that Docker tries to keep available. Use the same keys for single-server applications and for cluster applications. Appliku writes them into the generated docker-compose.yml in a different form for each deployment mode:

`appliku.yml` key	Single server (Docker Compose)	Cluster (Docker Swarm)
`resources_limits_memory`	`mem_limit`	`deploy.resources.limits.memory`
`resources_limits_cpus`	`cpus`	`deploy.resources.limits.cpus`
`resources_reservations_memory`	`mem_reservation`	`deploy.resources.reservations.memory`
`resources_reservations_cpus`	Not applied	`deploy.resources.reservations.cpus`

Use the Docker formats for the values. For memory, use a number with a k, m or g unit, for example "512m" or "1.5g". For CPUs, use a number of CPU cores, for example "0.5" or "2". Put the values in quotes.

services:
  web:
    command: gunicorn project.wsgi --log-file -
    resources_limits_memory: "1g"
    resources_limits_cpus: "1"
    resources_reservations_memory: "512m"

Important:

CPU reservations apply only in a cluster. Docker Compose has no CPU reservation. On a single server, Appliku keeps resources_reservations_cpus in the configuration, but does not apply it.
The memory reservation must not be more than the memory limit. Docker does not start a container with a reservation that is more than its limit. If this occurs on a single server, Appliku does not apply the reservation and writes a warning in the deployment log.
Limits apply only to the processes of the application. They do not apply to the release service, to one-off commands, or to the build of the image.
The memory limit does not include swap. If the server has swap, Docker can let the container use more swap memory.
An incorrect value can stop a deployment. Docker does not start a container with a value that it cannot read. Make sure that each value has the correct format.

The "Memory Limit" field on the "Processes" page of a single-server application overrides resources_limits_memory. But when Appliku applies appliku.yml, it replaces all process settings with the values from the file. Thus, if your application uses appliku.yml, set the memory limit in the file.

Databases¶

The databases section defines database services that will be provisioned for your application.

Available Database Types¶

Type	Key
PostgreSQL 19 + PostGIS (beta)	`postgresql_19`
PostgreSQL 18 + PostGIS	`postgresql_18`
PostgreSQL 17	`postgresql_17`
PostgreSQL 16	`postgresql_16`
PostgreSQL 15	`postgresql_15`
PostgreSQL 12	`postgresql_12`
PostGIS 16 + 3.4	`postgis_16_34`
PostgreSQL 16 + pgvector	`postgresql_16_pgvector`
TimescaleDB 15	`timescale_db_15`
MySQL 8	`mysql_8`
Redis 7	`redis_7`
Redis 6	`redis_6`
RabbitMQ	`rabbitmq`
Elasticsearch 8.17	`elasticsearch_8_17`

Example Databases¶

databases:
  db:
    type: postgresql_17
  redis:
    type: redis_7

Volumes¶

The volumes section defines persistent storage volumes for your application.

Volume Configuration Fields¶

target (string, required) — Path inside the container where volume is mounted
url (string, optional) — URL path for web access to volume
environment_variable (string, optional) — Environment variable name for volume path
source (string, optional) — Accepted, but Appliku does not use it. The files are always in /home/app/<app-name>/volumes/volume_<id> on the server.

The url must follow the volume URL rules. Two volumes cannot have the same location (/media and /media/ are the same).

Appliku creates only the volumes whose name the application does not have yet. If a volume with the same name exists, Appliku does not change it from the file. Edit it on the Volumes tab.

Example Volumes¶

volumes:
  media:
    target: /uploads/
    url: /media/
    environment_variable: MEDIA
  data:
    target: /app/data/
    environment_variable: DATA_PATH

Cron Jobs¶

The cronjobs section defines scheduled tasks that run at specified intervals.

Cron Job Configuration Fields¶

schedule (string, required) — Cron schedule expression
command (string, required) — Command to execute
timeout (integer, optional) — Time limit of one run in seconds, from 60 to 86400. If the key is not in the file, Appliku keeps the value that the job has (a new job gets 43200, 12 hours).

The schedule must follow the schedule rules. The command runs completely inside the container, see How the Command Runs.

Example Cron Jobs¶

cronjobs:
  send_emails:
    schedule: "0 * * * *"  # Every hour
    command: python manage.py send_emails
  daily_backup:
    schedule: "0 2 * * *"  # Daily at 2 AM
    command: python manage.py backup

How Appliku Applies the Section¶

At each deployment, Appliku makes the cron jobs of the application match the cronjobs section:

A job that is in the file but not in Appliku is created.
A job whose schedule, command or timeout is different is updated.
A job that is not in the file is deleted. This includes jobs that you added in the dashboard.
An update does not change whether a job is enabled or disabled. A new job is created enabled, except for a static site on a cluster: there it is created disabled, because cron jobs of static sites on a cluster never run.

If the file has no cronjobs key, Appliku does not change the cron jobs of the application. You can then manage them in the dashboard.

When the file has a cronjobs section, the Cron Jobs tab shows the jobs, but you cannot add, edit or delete them there. This is also true for the CLI and the API (they get the error "The cron jobs of this application are managed by the configuration file ..."). The time limit is also read-only: use the timeout key. To change a job, change the file and deploy. You can still turn a job on or off on the Cron Jobs tab (or with appliku crons update --id <job id> --enable / --disable); a deployment keeps this setting for a job that stays in the file.

The deployment log lists the jobs that a deployment deletes ("Cron jobs deleted because appliku.yml has no such job: ..."). After you click Save and Validate on the YAML Config tab, the YAML Config tab and the Cron Jobs tab warn you which dashboard jobs the next deployment deletes. To keep such a job, add it to the file before you deploy.

Warning

An empty cronjobs section deletes all cron jobs of the application at the next deployment. Both of these forms are empty:

cronjobs: {}

cronjobs:

To keep the cron jobs that you manage in the dashboard, remove the cronjobs key from the file.

Commands¶

The commands section lets you define a list of frequently used commands for your application. These commands appear as autocomplete suggestions in the Run Command tab, saving you from typing or copy-pasting them repeatedly.

The list is replaced on every deployment — whatever is in appliku.yml becomes the current set of suggestions.

commands:
  - python manage.py show_urls
  - python manage.py validate_templates
  - python manage.py check
  - python manage.py send_queued_mail

Note

These commands are only suggestions — nothing is run automatically. You still trigger execution manually from the Run Command tab.

Using the Configuration¶

Validation¶

The configuration file is automatically validated when: - You push code to your repository - You manually trigger a deployment - You import the configuration through the Appliku dashboard

If the file has errors, the deployment fails, the deployment log shows each error, and Appliku applies nothing from the file. Appliku also checks values that go to the server: service names (process name rule), output_directory (Build Settings), volume url values and cron schedule values.

Configuration Updates¶

When you update the appliku.yml file and push to your repository, Appliku will: 1. Validate the new configuration 2. Apply the changes to your application 3. Deploy the updated configuration

Exporting Configuration¶

You can export the current application configuration as an appliku.yml file from the Appliku dashboard.

Go to the application settings page, "YAML Config" tab, and click "Export YAML Config". You can then copy the contents to the clipboard or download it as an appliku.yml file and save it to your application repository.

The exported file uses only the keys that appliku.yml accepts, so you can import it again without changes. The CPU and memory limits of each process are exported as resources_* keys. For a single-server application, the export writes the memory limit that the deployment applies: the "Memory Limit" field of the process if it is set, or else resources_limits_memory. Thus, when you export and import the file again, the next deployment applies the same limits.

Complete Example¶

build_settings:
  build_image: python-3.14-uv-node-26
  build_command: npm run build
  container_port: 8000
  environment_variables:
    - name: DEBUG
      value: "false"
    - name: DATABASE_URL
      from_database:
        name: db
        property: connection_url
    - name: REDIS_URL
      from_database:
        name: redis
        property: connection_url
    - name: ALLOWED_HOSTS
      from_domains: true
    - name: SECRET_KEY
      source: manual

services:
  web:
    command: gunicorn project.wsgi --log-file -
    scale: 2
  worker:
    command: celery -A project worker -l info
    scale: 1
  release:
    command: python manage.py migrate

databases:
  db:
    type: postgresql_17
  redis:
    type: redis_7

volumes:
  media:
    target: /app/media/
    url: /media/
    environment_variable: MEDIA_ROOT

cronjobs:
  cleanup:
    schedule: "0 3 * * *"
    command: python manage.py cleanup_old_files

commands:
  - python manage.py show_urls
  - python manage.py validate_templates
  - python manage.py check
  - python manage.py send_queued_mail