# Nais Manifest > Create, change or review Nais Application and Naisjob deployment resources. Use for ingress, probes, resource limits, access policies, scaling or scheduled jobs; use `nav-troubleshoot` to diagnose a live workload and specialist skills for application code. - Skill: `navikt/nais-manifest-2` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add navikt/nais-manifest-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/navikt/nais-manifest-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: navikt (https://skillmd.com/u/navikt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/navikt/nais-manifest-2 --- # Create or change a Nais manifest > **OpenCode v1:** Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native `skill` tool. Slash commands are direct user entry points only. ## Inspect deployed intent first Find existing Nais resources, environment overlays, templating, deployment workflows, app configuration, server startup, health and metrics routes, runtime type, external calls, auth, Kafka, database configuration, and production telemetry. Search the repository rather than assuming `.nais/`, `nais/`, file names, or one manifest per environment. Derive application name, namespace, team label, image placeholder, port, probes, ingress, resource values, environment variables, pools, database type, and access policy from repository evidence. Treat recognized `AGENTS.md`/instruction sources as declared context and rationale, then verify names, topology and effective values against manifests, code, workflows, telemetry or current authoritative platform documentation. If the sources conflict, stop and ask rather than silently preferring either one. If no manifest exists, ask the user for owning team, app name, target environments, runtime port, required dependencies, exposure, and operational expectations. Confirm the current Nais schema and supported resource versions before creating a new resource. ## Choose the resource kind - Use `Application` for a continuously running HTTP service, worker, or Kafka consumer. - Use `Naisjob` for bounded scheduled or manually triggered work that exits. - Do not turn a frequent or continuous queue consumer into a cron job. Reuse the repository's environment and templating strategy. Do not introduce separate dev/prod files, variables, or a new renderer when the repository uses a different established pattern. ## Start from an evidence-filled Application shape ```yaml apiVersion: nais.io/v1alpha1 kind: Application metadata: name: namespace: labels: team: spec: image: {{ image }} port: prometheus: enabled: true path: liveness: path: initialDelay: readiness: path: initialDelay: resources: requests: cpu: memory: limits: memory: ``` Every endpoint in the manifest must exist on the configured port in every deployed startup mode. Do not copy conventional health paths into a repository that exposes different ones. ## Resource rules Normally omit `resources.limits.cpu` for a Nais workload, in line with current Nais cost and good-practice guidance. CPU quota throttling can amplify JVM startup, GC, and latency problems. Verify current platform guidance and retain an evidenced exception when the workload deliberately needs CPU-constrained testing or another owner-approved bound. Set a CPU request for scheduling and retain a measured memory limit so the pod cannot consume unbounded node memory. Treat example sizes as hypotheses, not defaults. Compare current telemetry, heap and off-heap use, workload concurrency, replicas, autoscaling, startup, and peak behavior. Keep memory headroom above JVM heap for metaspace, threads, native libraries, and direct buffers. Production resource or replica changes require user approval and fresh evidence. ## Keep access policy explicit and minimal List the applications and external hosts the workload actually communicates with. Include namespace and cluster when required by the real topology: ```yaml accessPolicy: inbound: rules: - application: namespace: outbound: rules: - application: namespace: external: - host: ``` An empty or absent inbound rule set does not grant callers through the service-discovery/accessPolicy path. It does not block traffic through an ingress. Review ingress exposure, edge authentication and application-level authorization as separate controls; never present `accessPolicy.inbound` as a complete caller inventory or ingress firewall. Do not add a fake inbound caller merely to make the block non-empty. Keep policy aligned with application token validation and authorization. Require security review for changes to callers, destinations, auth flags, ingress or scopes. ## Add platform capabilities only when code uses them ### PostgreSQL ```yaml gcp: sqlInstances: - type: tier: highAvailability: diskAutoresize: databases: - name: envVarPrefix: ``` Verify the supported Postgres type, tier, HA, backup and disk choices against current Nais documentation and repository needs. Follow the prefix already mapped by application config; do not copy a database environment prefix from another service. Size connection pools against replicas and actual `max_connections`. Ensure long startup migrations fit the repository's startup and probe design. ### Kafka ```yaml kafka: pool: ``` Match the pool to the environment and owned topic resources. A Kafka block does not provision a topic; use the owning Kafkarator workflow and explicit ACLs. ### Authentication ```yaml azure: application: enabled: true tokenx: enabled: true ``` Enable only mechanisms required by verified incoming and outgoing flows. Keep their access policy and application validation aligned. Do not copy tenants, scopes, audiences, or sidecar annotations from another app. ### Ingress Choose a public, internal, or external Nav domain from the actual audience and current platform policy. A service called only by other Nais applications may need no ingress. Adding or widening ingress changes the trust boundary and requires approval. ### Observability Use the runtime and observability form already supported by the repository and current Nais schema. Ensure logs go to stdout or stderr without personal data, metrics match `prometheus.path`, and tracing does not capture tokens or payloads. ## Preserve pod lifecycle Use the application's framework shutdown and owned-resource cleanup. Do not invent manual readiness toggles or duplicate shutdown hooks. Load [references/pod-lifecycle.md](references/pod-lifecycle.md) when changing grace periods, pre-stop behavior, workers, consumers, or long-running requests. ## Create Naisjob deliberately A Naisjob needs an explicit schedule or manual invocation model, overlap policy, deadline, retry limit, cleanup policy, resources, and only the platform capabilities it actually uses. Load the portable example in [references/naisjob-example.md](references/naisjob-example.md). ## Deliver evidence Validate the rendered manifest with the repository's existing tooling and current Nais schema. Return the source and rendered resource, values derived from code, environment differences, security and cost changes, probe evidence, and validation command with exit code. Mark unverified capacity or platform assumptions explicitly. Record hard-to-reverse platform decisions through the repository's ADR process after the user accepts them. ## Boundaries ### Ask first - Change production resources, replicas, autoscaling, ingress, access policy, database tier or HA, Kafka pool, or paid GCP resources. - Add a new resource kind or deployment strategy. ### Never - Add `resources.limits.cpu` without current Nais guidance and an evidenced, owner-approved exception, or remove the memory limit without equivalent measured protection. - Store secrets in Git or copy another application's identity values. - Invent paths, namespaces, ports, probes, environment prefixes, or callers. - Lower the termination grace period without measured shutdown evidence.