items.applicationManagement.title

Manage all your deployed applications from a central location. Monitor status, update configurations, scale deployments, and maintain your Kubernetes applications effectively.

Overview

The Application Management dashboard provides comprehensive tools for:

• Real-time application monitoring
• Configuration management
• Scaling operations
• Troubleshooting and diagnostics
• Lifecycle management

Accessing Application Management

Navigate to Applications in your dashboard to view all deployed applications across your clusters.

Application Dashboard

Application List

The main dashboard shows:

• Application name and namespace
• Current status (Running, Pending, Failed, etc.)
• Resource usage (CPU, Memory)
• Age and last update
• Quick action buttons

Diagnostic Tools

Logs

• View application logs
• Filter by pod or container
• Search and export logs

Metrics

• Review resource usage for the application
• Check recent performance trends
• Compare behavior before and after a deployment

Events

• Inspect rollout failures and restart patterns
• Review scheduling or image pull issues
• Confirm whether recent configuration changes affected the workload

Configuration Review

Application Management is also where teams verify the deployment context around a running workload.

Common checks include:

• Namespace and target cluster
• Image and tag currently deployed
• Replicas and scaling configuration
• Service exposure and ingress state

Typical Workflow

1. Open the application from the Applications list
2. Confirm the current runtime status
3. Review logs, metrics, and recent events
4. Check the deployed configuration
5. Move to the relevant deployment or pipeline flow if a change is required

Repository Deployment Config

NebuaCloud can read a file named nebuacloud.yml from the root of your repository and use it as the default deployment configuration for that repo.

This is useful when you want the repository to describe how it should be built and deployed instead of relying only on auto-detection.

Application Stacks are different. They manage runtime infrastructure manifests and are documented separately in Application Stacks.

Example nebuacloud.yml

app:
	name: nebua-portal
	root: frontend
	port: 3000

runtime:
	type: node
	version: "20"

build:
	install:
		- pnpm install --frozen-lockfile
	preBuild:
		- pnpm run lint
	build:
		- pnpm run build
	postBuild:
		- pnpm run test:smoke
	start:
		- pnpm run start
	outputDirectory: dist
	overrideBuild: false

deploy:
	imageTagMode: latest

env:
	NODE_ENV: production
	GATSBY_API_URL: https://api.example.com
	GATSBY_PUBLIC_APP_NAME: Nebua Portal

What Each Section Does

• app.name: Optional application name metadata.
• app.root: Monorepo subdirectory to use as the build context, such as frontend or backend/api.
• app.port: Container port for the runtime application.
• runtime: Runtime type and version. Supported values are node, python, and dotnet.
• build.install, build.preBuild, build.build, build.postBuild: Command lists executed during the workflow.
• build.start: Start command used when NebuaCloud generates the runtime Dockerfile.
• build.outputDirectory: Static output folder for web builds, for example dist or build.
• build.overrideBuild: When true, NebuaCloud skips the detected default build command and uses only the custom build commands.
• deploy.imageTagMode: Image tag strategy. Supported values are service, latest, and custom.
• env: Environment variables injected into the build workflow and the deployed container.

Merge Priority

NebuaCloud resolves deployment configuration in this order:

1. Values sent from the UI or API
2. Values from nebuacloud.yml
3. Automatic framework detection

That means repo defaults are applied automatically, but an operator can still override them from deployment settings when needed.

Notes And Constraints

• nebuacloud.yml must be placed at the repository root.
• Command entries must be single-line strings.
• Dangerous commands are blocked and ignored.
• Unsupported or invalid values are skipped and shown as warnings in deployment status.
• deploy.namespace and deploy.environmentId are intentionally ignored for security reasons.
• Current support is for a single app definition per repository. The format is designed to expand later.

Git Integration: Auto-Deploy On Push Or Pull Request

Git Integration is a separate flow from the manual "Deploy" button covered above. Instead of triggering a build yourself, you connect a repository once and NebuaCloud redeploys the app automatically whenever your team pushes to a mapped branch, or optionally on pull/merge requests. Configure it from an application's Git Integration page.

There are two ways to tell NebuaCloud which branch should deploy to which environment:

1. In the UI - set the branch for each environment directly on the Git Integration page. This always takes priority when set.
2. In nebuacloud.yml - add a deploy entry per environment name, each with a branch key:

deploy:
  production:
    branch: main
  staging:
    branch: develop

This can be combined with the build/runtime keys documented above in the same file - the environment names under deploy don't collide with deploy.imageTagMode or the other build-related deploy keys.

When a webhook event arrives, NebuaCloud resolves the target environment in this order:

1. The explicit branch-to-environment mapping saved on the Git Integration page.
2. The deploy.<environmentName>.branch mapping from nebuacloud.yml, read from the branch the event happened on.
3. If neither matches, the event is skipped.

How NebuaCloud Finds Out About A Push

nebuacloud.yml on its own does not notify NebuaCloud of anything - GitHub, GitLab, and Azure DevOps have no built-in awareness of that file or of NebuaCloud. The trigger is a webhook you register directly on the repository, in that provider's own settings (GitHub → Settings → Webhooks, GitLab → Settings → Webhooks, Azure DevOps → Project Settings → Service Hooks), pointing at the URL NebuaCloud generates when you save the Git Integration. The provider POSTs push/PR events to that URL; NebuaCloud verifies the request using the webhook secret, and only then reads nebuacloud.yml from that same repository to resolve the target environment.

Setting It Up

1. Open the application's Git Integration page and connect a provider account (GitHub, GitLab, Bitbucket, or Azure DevOps) via the popup authorization flow.
2. Pick the repository and set the default branch.
3. Save the integration - this generates a webhook URL and secret.
4. Add that webhook to the repository yourself, in the provider's own webhook settings, using the copyable URL and secret. NebuaCloud does not currently register the webhook on your behalf, even for connected OAuth accounts.
   • GitHub, GitLab, and Bitbucket all support a secret that signs each delivery (X-Hub-Signature-256, X-Gitlab-Token, etc.) - paste the copied secret into that field.
   • Azure DevOps is different. Its "Web Hooks" service hook has no secret/signature field at all - the only authentication it offers is optional HTTP Basic auth. When creating the service hook, enable Basic authentication and enter any username (it isn't checked) with the copied secret as the password. A prior version of this integration expected a signature header Azure DevOps never actually sends, which silently rejected every Azure DevOps webhook delivery - fixed, but worth knowing if you configured one before and it never triggered.
5. Toggle Auto-deploy on push and, if wanted, React to pull request / merge request and Create preview deployments.

Notes And Constraints

• The "Current source repository" field on the Git Integration page only shows a value once a real repository is on record for the app (either from the build-from-repo pipeline or from a saved Git Integration) - template- based or Compose-imported apps show no source repository until one is connected here.
• Preview deployments and pull/merge-request triggers are opt-in per application.
• Webhook secrets can be rotated at any time from the Git Integration page; rotating invalidates the previous secret immediately.

Troubleshooting

Application Is Unhealthy

• Review container logs first
• Check pod restart counts and recent events
• Verify configuration, secrets, and image values

Recent Deployment Caused Problems

• Compare the current state with the previous release
• Check pipeline output and rollout events
• Confirm the correct environment received the change

Related Documentation

• Applications - Inventory and navigation for all applications
• Application Stacks - Runtime infrastructure stacks and Stack API usage
• Kubernetes - Inspect cluster workloads and services
• Monitoring - Investigate metrics and alert state
• Logs - Debug runtime output