Applications

An application runs a container image in a project environment. Create its configuration, deploy a revision, and use its detail page to inspect replicas, logs, and routes.

Find your way around

Open an application from its project environment or the Applications list. The header shows its status, image, version, and internal hostname. The hostname is for other services on its private network; adding a public route is a separate choice.

Your role determines which tabs and actions are available. The Save changes bar stays at the bottom while you edit. Save before deploying; use Discard when you want to abandon a form change.

Before you start

Have a project environment assigned to a cluster and an image that its nodes can pull. Your role needs Manage workloads to create or edit an application and Manage deployments to deploy or operate it. Environment variables and managed file content require Manage secrets. Logs require View logs.

For a web application, know the port on which the container serves requests. For a private image, have the appropriate registry connection available in Upvale. For a custom hostname, have access to its DNS records and the public ingress address for your cluster.

Create an application

1. Open Workloads, then open your project.
2. Choose the intended environment in the environment selector beside the project name.
3. Select Add Service → Application. The New application page keeps the project selected.
4. Under Basics, enter a Name.
5. Under Image, enter Repository and Tag, then choose Registry.
6. Under Runtime, enter the Container port for a web service, choose Replicas, and set Placement. The initial replica count is 1 and placement is Automatic — any available node.
7. Configure any resources, storage, health check, environment variables, and routes needed by the image, using the sections below.
8. Select Create application. Upvale opens the application's detail page.
9. Select Deploy as revision v1 in the header. Follow the queued operation, then open Deployments to check Last successful deployment and Running replicas.

Creating the application saves its configuration. Deployment is a separate action.

A simple first application

For a first deployment, use a public web-server image:

Leave the other sections unchanged. Add a route with your own hostname, or use sslip.io if the cluster offers it. Create the application, deploy it, then use Open route. For your own image, replace the repository, tag, and port with those used by your application.

Upvale runs container images. Build and push your image before deploying it; entering a Git repository here does not build the application.

Choose the image and registry

Enter the repository and tag separately. Do not append :tag to Repository.

The saved registry supplies its host, so omit that host from Repository when using the connection. Replace the example namespace, repository, and tag with an image you can access. A deployment resolves the tag to the image digest it will run.

Runtime and placement

The application must listen on an address reachable from outside its container, usually 0.0.0.0, rather than only 127.0.0.1. Increasing replicas does not copy local files or make a stateful application safe for multiple writers.

Set environment variables

With Manage secrets, open Environment variables and select Add variable. Enter the variable name, then choose the value source:

• value stores the value entered in the row.
• secret lets you select an existing secret available to the project.

You can switch from Rows to Editor to enter one NAME=value per line. For example:

LOG_LEVEL=info
API_TOKEN=[API_TOKEN]

[API_TOKEN] refers to a stored secret named API_TOKEN; create that secret before referencing it. The brackets have special meaning in the editor. If a name exists at both project and organization scope, use [API_TOKEN@project] or [API_TOKEN@organization].

Secret references are resolved at deployment time. Save and deploy a configuration change before expecting it in the running application.

Add persistent storage

In Storage, select Volume mount and enter:

• Logical volume name: the name of this application's volume.
• Container path: the absolute path where the image writes its data, such as /app/data when that is the path required by your image.
• Read-only: enable this only when the application should not write to the mount.

Volume names are scoped to the service. Local volumes belong to a particular node: the same logical name on another node does not contain the same data. For persistent local data, choose the intended node under Runtime → Placement → Specific node. Changing placement does not migrate the data.

Multiple replicas may write to a mounted volume concurrently. Use multiple writers only when the application and storage support them. Applications with writable persistent mounts can have an interruption during deployment while the previous writer is stopped before its replacement starts.

File mount is available with Manage secrets. Enter File name, an absolute Container file path including the filename, and File content. This produces a read-only configuration file, with a maximum of 500 KB. Use environment secrets for credentials; do not put passwords or private keys in file content.

Set resources and a health check

Resources provides vCore limit, Memory limit (MB), Shared memory (MB), and optional process limits. Fractional vCore limits such as 0.5 are accepted. Shared memory is private to each container and counts toward its memory limit; leaving it blank uses Docker's 64 MB default.

In Health check, enter a Command and configure Interval (seconds), Timeout (seconds), Retries, and Start period (seconds). The command runs through CMD-SHELL inside the container, so the image must contain the command and any tools it uses.

Resource limits

The ulimit selector supports these limits:

Health-check fields

Use a command supplied by the image or a tool installed in it. A curl health check cannot work in an image without curl.

Add a public route

1. In Routes, select Add route.
2. Enter Hostname, without a scheme or path, and set Public path, usually /.
3. Set Target port if the route should use a port other than the application's Container port, or if no application port is set.
4. Choose TLS mode. Use Automatic certificate and Let's Encrypt when available for your cluster. HTTP only requests no certificate.
5. Keep Default Entrypoint (80/443) unless your cluster has a specific configured entrypoint for this route.
6. Point your hostname's DNS records to the cluster's public ingress address. If the sslip.io button is available, it can generate a hostname from an available ingress address instead.
7. Create the application, or select Save changes when editing an existing one, then deploy the revision.
8. Check the route's DNS and Certificate status. Use Recheck DNS after correcting DNS records and Retry certificate when a certificate request needs retrying. Select Open route to visit it.

Automatic certificates depend on the cluster's ingress configuration and reachable DNS. If Let's Encrypt is unavailable, ask the person who manages your cluster to check it.

Full view adds Internal path, middleware references, and Strip public path before forwarding. For TLS routes it also shows Redirect HTTP after the certificate is verified. Use custom resolvers, uploaded certificates, entrypoints, and middleware names only when they have already been configured for your cluster.

Change and deploy an application

Open the application's Application tab. Update Image & Deployment, Runtime, Resources, Storage, Health check, Environment variables, or Routes, then select Save changes.

For process overrides after creation, use Advanced. Process and isolation includes Entrypoint command, Command arguments, Working directory, and Run as user. Save these changes and deploy the resulting revision in the same way.

The confirmation identifies the saved revision and tells you to deploy it. Select Deploy as revision vN to apply that revision. Saving changes does not change the running service, and edits made after a deployment is queued do not alter that queued deployment.

The header also provides these runtime actions after deployment:

Use a deployment to apply a changed image, environment, route, or runtime setting. Restart does not apply a pending revision.

Check a deployment or restore a revision

In Deployments, compare Desired configuration with Last successful deployment. Running replicas shows the node, image, service revision, state, and any task error. Expand Starting and previous replicas when investigating a failed start.

Use Revision history → Compare revisions to inspect changes. Choose From and To, or use Compare on a revision row.

To restore an available earlier configuration, select its Roll back action and confirm Roll back. Upvale restores that configuration as a new revision and starts a deployment. This does not reverse changes to application data or database schemas.

Open Logs for container output. Monitoring is available with View monitoring. Terminal and protected configuration controls depend on your permissions.

If an application displays a Compose ownership notice, edit and deploy it through its project environment's Compose workflow. Its individual deployment and configuration controls are restricted by that ownership.

Deployment automation

Open Application → Image & Deployment → Deployment automation to trigger deployments from a CI pipeline.

1. Select Enable webhook.
2. Copy the webhook URL and the one-time secret. Store the secret in your CI system's secret store.
3. Build and push the new image in CI.
4. Send the request shown under Request example, using the new image tag.
5. Follow the deployment in Upvale. Last used, Last image tag, and Last commit help confirm that CI reached the webhook.

The request uses Authorization: Bearer with the webhook secret. Use a stable Idempotency-Key, such as the commit SHA, so a repeated CI request does not start another deployment for the same release. The example body includes tag, commitSha, and branch.

Rotate secret invalidates the previous secret. Update your CI secret after rotating it. Disable stops further requests through the webhook. This webhook belongs to the application; it is separate from an account API token.

Advanced application settings

Open Advanced after creating the application. Save and deploy a new revision to apply these options.

Process and isolation

Command fields do not expand environment variables or interpret shell syntax. For a shell script, explicitly run a shell: use command rows sh, -c, and put the script in one argument row.

Published ports

Use Add published port for direct TCP or UDP access that does not use an HTTP route.

Allow only the required traffic in the node or cloud firewall. Published ports bypass the application's HTTP routes and their HTTP security settings. Changes can briefly interrupt connections. See Networking for the distinction between service networks, ingress, and node connectivity.

Restart policy

For a command that should finish once, use a scheduled job so you can track each execution separately.

Host access, capabilities, and sysctls

Host bind mount is available in Application → Storage to roles with Privileged workloads. Set the existing absolute Host path, its Container path, and whether the mount is Read-only. Upvale does not create, move, or delete that host path. It must exist on each node that can run the application.

Under Advanced → Linux capabilities and sysctls:

• Add capabilities grants specific Linux capabilities to the container.
• Drop capabilities removes capabilities the container would otherwise have.
• Sysctls sets supported kernel parameters by name and value. Docker and the host determine which parameters are allowed.

These options require Privileged workloads permission. Host mounts and added capabilities can give a container access to its server; use only the permissions the image actually needs. The form asks for an explicit acknowledgement when privileged settings are configured.

HTTP security settings

The Security tab applies to generated Traefik routing. These settings do not inspect database traffic or traffic using direct published ports. Save and deploy them like other application configuration.

These headers override matching headers returned by the application. If you use custom routing YAML, maintain the corresponding middleware yourself or restore generated routing before using these controls. The Routes and Traefik guide explains routing and traffic changes in more detail.

Traefik tab

Upvale creates the application's routing file on its first deployment. While it is generated, changes in Routes and Security update that file.

Saving a manual edit in Traefik switches the file to manual management. Later route edits do not overwrite your YAML. Use Browse cluster files for the wider cluster routing configuration. Restore defaults regenerates this application's file from its saved route settings and starts the normal deployment flow; it discards manual changes to that file.

See Routes and Traefik for the file editor, versions, validation, and custom routing examples.

Logs, metrics, and terminals

In Logs, choose the service task, the number of tail lines, and all output, stdout, or stderr. Search filters the loaded output. Download saves the lines currently displayed. Refresh or reconnect if the selected container has been replaced.

In Monitoring, select a running replica or a previous replica and the time range you want to inspect. This helps distinguish a single busy container from a problem affecting the whole application.

To open a shell, select Deployments → Running replicas → Terminal on the intended replica. Terminals require the terminal permission and a running reachable container. Files changed inside a container may disappear when it is replaced; save persistent changes in the image, configuration, or mounted storage.

Remove an application

Open Application → Danger zone → Delete application and type the name to confirm. This removes the service and routes but keeps named volumes. Follow the cleanup operation before treating the application as removed. Review retained volumes in Storage.

If no manager can perform cleanup, Remove application record only removes Upvale's records and leaves infrastructure on the servers. It requires an explicit acknowledgement. Use this only when you intend to handle that infrastructure separately.

Common problems