Application Management

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.

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