Skip to main content

App Advanced Settings

The App page organizes configuration into sidebar sections. General deployment configuration is under App Config; network policy is under Network; health checks are under HTTP Probes; and runtime container behavior is under Container Settings.

Environment-specific settings, including startup command overrides, are on the individual app environment page.

Startup command​

Open the environment and select Settings → Advanced settings, then use Startup command when the same image or build must start differently in each environment. You can set a complete shell command, exact arguments, direct execution, and a working directory without rebuilding the image.

Saving creates a pending deploy change. Select Apply changes or include it in the next deployment. Reset to image defaults removes the whole override.

See Startup Command Overrides for dashboard, CLI, API, MCP, and image-entrypoint behavior.

SockJS path-based session affinity​

For an HTTP App environment, enable SockJS path-based session affinity when cross-origin or cookieless clients, such as Cordova apps, must use SockJS HTTP fallback. Quave ONE then routes requests under /sockjs/<server>/<session>/... using the SockJS server and session IDs. All transports for one session reach the same container without depending on a cookie.

This setting is off by default and applies only to the selected environment. It is independent from the App-level Sticky Sessions option, which keeps cookie affinity for ordinary application traffic. Saving the setting creates a pending deploy change; select Apply Changes before the new routing takes effect. Branch previews copy the source environment's setting.

Changing the setting, deploying, or scaling can interrupt an in-flight SockJS fallback session. Clients should reconnect normally and create a new session. The setting is not available for Databases & Services, Functions, Jobs, or TCP-only environments.

Switching Deployment Method​

You can switch between CLI and GitHub deployment methods from App Config.

From CLI to GitHub​

If your app is currently deployed via CLI and you want to connect it to a GitHub repository:

  1. Open the App's App Config section
  2. Under Deployment Method, click Switch to GitHub
  3. Follow the prompts to connect your GitHub repository
  4. All environments will be updated to use the default branch from your repository

After connecting, configure each environment's branch under Settings.

From GitHub to CLI​

If your app is connected to GitHub and you want to switch to CLI deployment:

  1. Open the App's App Config section
  2. Under the GitHub repository information, click Disconnect GitHub - Switch to CLI
  3. Confirm the disconnection

After disconnecting, future deploys will need to be done via the CLI or GitHub Actions.

Note: You can always reconnect to GitHub later if needed by following the "From CLI to GitHub" steps above.

Sticky Sessions​

Enable Sticky Sessions in the App's Container Settings section when you want to keep the same client connecting to the same container.

This depends a lot on your stack, for example, if your server keep state of the connected client it's probably a good idea to enable Sticky Sessions.

Now if your app is stateless, like a REST API, you probably don't need Sticky Sessions.

Without Sticky Sessions enabled your connections will be more balanced across all the containers so just use it if you really need it.

Blue/green deployment​

Enable Blue/green deployment in the App's Container Settings section in most cases, because it supports zero-downtime deployments: your old containers stay alive and keep serving traffic while the new containers are not passing the health check.

What it does today: the option is implemented as a Kubernetes rolling update with 25% max surge and 25% max unavailable, not as a second full stack that is swapped in at once. Containers are replaced in batches of ceil(25% of replicas) while at most floor(25% of replicas) are unavailable, so 3 replicas roll out in 3 waves and 4 or more replicas roll out in 2 waves.

Make sure you customize your health check so your new containers are only going to be ready when your app is really ready to accept new requests.

Every probe that has to pass before a new container can take traffic is paid once per wave. That is why the startup probe is optional and off by default: enable it only for apps that need a distinct slow-start gate. The readiness and liveness probes start after a 5 second initial delay; an enabled startup probe starts probing immediately (initial delay 0 seconds) at its configured period. See HTTP Probes for the accepted values (periodSeconds 1-300, failureThreshold 1-120).

Termination grace period​

For apps that drain connections on SIGTERM (for example Meteor apps using @meteorjs/ddp-graceful-shutdown with METEOR_SIGTERM_GRACE_PERIOD_SECONDS), the Kubernetes pod terminationGracePeriodSeconds must be longer than the in-app drain window plus a small margin. Otherwise Kubernetes may kill the pod before graceful shutdown completes.

Set Termination grace period (seconds) in Container Settings, or via the Public API / MCP tools using terminationGracePeriod (seconds). The deploy payload sends terminationGracePeriodSeconds to the cluster.

Example: METEOR_SIGTERM_GRACE_PERIOD_SECONDS=30 and terminationGracePeriod=45 gives ~15 seconds of margin after DDP drain.

Recommended values:

  • Minimum: 1 second (platform validation)
  • Maximum: 3600 seconds (60 minutes)
  • When unset: Kubernetes default (currently 30 seconds)
  • Set terminationGracePeriod greater than your in-app SIGTERM drain duration

Block communication from other accounts​

Enable Block communication from other accounts in the App's Network section in most cases, so the app environments accept connections only from our ingress and other app environments in the same account.

This is a security measure to avoid your app env to be exposed to other containers running in our clusters that don't belong to your account.

If you run multiple accounts where your containers talk to each other across accounts then you should disable this option, so you can connect your app envs between accounts.