> ## Documentation Index
> Fetch the complete documentation index at: https://novita.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Build & beheer

## Build

Zodra een sjabloondefinitie klaar is, gebruik je `Template.build(...)` om deze te builden. De build accepteert een sjabloonnaam plus optionele buildinstellingen zoals CPU, geheugen, tags, cachegedrag en een callback voor buildlogs.

<CodeGroup>
  ```ts JavaScript & TypeScript icon="js" theme={"system"}
  import { Sandbox, Template } from "novita-sandbox"

  const template = Template().fromImage("python:3.12")

  const build = await Template.build(template, "my-python-template", {
    cpuCount: 2,
    memoryMB: 1024,
  })

  const sandbox = await Sandbox.create(build.templateId)
  console.log(sandbox.sandboxId)

  await sandbox.kill()
  ```

  ```python Python icon="python" theme={"system"}
  from novita_sandbox.core import Sandbox, Template

  template = Template().from_image("python:3.12")

  build = Template.build(
      template,
      "my-python-template",
      cpu_count=2,
      memory_mb=1024,
  )

  sandbox = Sandbox.create(build.template_id)
  print(sandbox.sandbox_id)

  sandbox.kill()
  ```
</CodeGroup>

Als je een build wilt maken zonder te wachten tot het volledige proces klaar is, gebruik dan `Template.buildInBackground(...)` / `Template.build_in_background(...)` en controleer later de buildstatus.

## Namen

Elke build heeft een sjabloonnaam nodig. Houd namen stabiel voor een logische sjabloonfamilie, bijvoorbeeld:

* `my-python-template`
* `agent-runtime-base`
* `sandbox-webapp`

Behandel de naam als de langlevende identiteit van de sjabloonfamilie. De geretourneerde sjabloon-ID is de onveranderlijke buildoutput die je tijdens runtime gebruikt.

## Tags & versiebeheer

Met tags kun je builds labelen voor releasemanagement zonder de onderliggende sjabloonnaam te wijzigen.

Typische patronen zijn onder andere:

* semantische versies zoals `v1.0.0`
* promotielabels zoals `staging` of `production`
* bewegende kanalen zoals `latest`

Je kunt tags toewijzen tijdens de build of na de build met de template tag APIs.

<CodeGroup>
  ```ts JavaScript & TypeScript icon="js" theme={"system"}
  import { Template } from "novita-sandbox"

  const template = Template().fromPythonImage("3.12")

  const build = await Template.build(template, "agent-runtime-base", {
    tags: ["v1.0.0", "latest"],
  })

  await Template.assignTags("agent-runtime-base:v1.0.0", "production")

  const tags = await Template.getTags(build.templateId)
  console.log(tags)
  ```

  ```python Python icon="python" theme={"system"}
  from novita_sandbox.core import Template

  template = Template().from_python_image("3.12")

  build = Template.build(
      template,
      "agent-runtime-base",
      tags=["v1.0.0", "latest"],
  )

  Template.assign_tags("agent-runtime-base:v1.0.0", "production")

  tags = Template.get_tags(build.template_id)
  print(tags)
  ```
</CodeGroup>

Gebruik namen voor de sjabloonfamilie en tags voor releasemarkeringen. Zo blijven roll-forward- en rollback-workflows eenvoudig.

## Logging

Buildlogs helpen je de voortgang van provisioning te inspecteren en fouten te diagnosticeren.

Geef in JavaScript en TypeScript `onBuildLogs` door aan `Template.build(...)`. De SDK exporteert ook `defaultBuildLogger(...)` voor een standaard consolelogger.

<CodeGroup>
  ```ts JavaScript & TypeScript icon="js" theme={"system"}
  import { Template, defaultBuildLogger } from "novita-sandbox"

  const template = Template().fromPythonImage("3.12")

  await Template.build(template, "my-logged-template", {
    onBuildLogs: defaultBuildLogger({ minLevel: "info" }),
  })
  ```

  ```python Python icon="python" theme={"system"}
  from novita_sandbox.core import Template

  template = Template().from_python_image("3.12")

  build = Template.build(template, "my-logged-template")
  print(build.build_id)
  ```
</CodeGroup>

Als je op de achtergrond buildt, gebruik dan `Template.getBuildStatus(...)` / `Template.get_build_status(...)` om de status te pollen en later logvermeldingen op te halen.

## Foutafhandeling

Sjabloonbuilds kunnen om verschillende veelvoorkomende redenen mislukken:

* ongeldige referenties voor een privéregistry
* mislukte pakketinstallaties binnen `runCmd(...)` / `run_cmd(...)`
* een startopdracht die onverwacht wordt afgesloten
* een ready-opdracht die nooit slaagt
* CPU- en geheugeninstellingen die niet voldoen aan de platformlimieten

Wanneer een build mislukt:

1. inspecteer eerst de buildlogs
2. valideer de bronimage of Dockerfile van het sjabloon
3. voer opnieuw uit met uitgeschakelde cache als je een verouderde laag vermoedt
4. reduceer het sjabloon tot de kleinste instructiereeks die nog faalt

Controleer bij asynchrone buildflows de geretourneerde buildstatus. De SDK stelt statussen beschikbaar zoals `building`, `waiting`, `ready` en `error`.