Skip to content
+1 (813) 212-3723 support@layeronecloud.com

Configure your application

Set the start command, port, CPU, memory and disk, and an optional health check. Changes apply on deploy.

2 min read

The Settings tab holds how your application runs and how large it is. Saving settings does not restart anything on its own: you choose Save only, or Save and deploy to apply them now. Settings otherwise take effect on your next deploy.

Start command

The Start command is what runs inside the container, for example gunicorn app.wsgi --bind 0.0.0.0:8080. Leave it blank to use the image's own entry point.

No shell, just a command

The start command is run as a plain argument list, not through a shell, so pipes, &&, redirects and environment-variable expansion in the command line do not work. If you need those, put them in a script in your image and run the script.

App port

App port is the port your application listens on. Traffic is routed here, so it must match what your process binds. The default is 8080. A running release keeps its port until the next deploy.

Resources

Each application runs a single instance. Its size is set here:

Field Range Default
vCPUs 1 to 32 4
Memory 512 MB to 32 GB 4 GB
Disk 8 GB to 500 GB 8 GB

You pay for what the instance actually uses, not the ceiling you set, except disk, which is billed on what you allocate. See How applications are billed. Memory and CPU can go up or down between deploys; disk can only grow, so a smaller disk is refused.

Guests are memory-tight

An application's memory is a hard ceiling with no swap. A process that exceeds it is killed rather than slowed, which can look like a crash with no error. Give a hungry app more headroom, and watch its metrics.

Health checks

A health check holds traffic back until the app is actually ready. It is off by default, in which case a new instance is considered ready once it has stayed running for a few seconds.

Turn it on to give a Health check path, such as /healthz, which is fetched on your app's port. The instance is given traffic only once that path answers with a success response. A path that never answers keeps the old release serving, which is what you want: a broken deploy does not take the app down.

Delete an application

At the bottom of Settings, Delete application removes it for good: every instance, its disk, its builds, releases and variables, and it frees the identifier. You confirm by typing the identifier. If the app deploys from GitHub, its push webhook is removed too. Deleting is the only thing that stops its charges.

Still stuck

Ask AI or open a ticket.

Ask AI in the portal answers from these docs. For anything it cannot settle, open a ticket and an engineer replies by email.