Customize an Instance

Nautobot Cloud lets you tailor a Nautobot instance to your needs — directly from the Console. You can:

• Install custom Apps from public PyPI or from a package you upload.
• Configure App settings (the equivalent of PLUGINS_CONFIG in nautobot_config.py).
• Declare pip dependencies — extra Python libraries your Jobs or customizations need.
• Upload static files — assets such as templates or a custom logo for branding.

Together these give you self-service control over your deployed Nautobot instances.

Your customizations are your responsibility

Custom Apps, pip dependencies, static files, and App configuration run your own code and packages. Network to Code certifies and supports the base Nautobot image and Marketplace Apps — but not the customizations you add on top. You are responsible for making sure they are compatible and work correctly, and for testing them thoroughly (ideally in a lower environment first — see Environments & Promotion) before applying them to production.

Where to Find It

Open an instance from Manage Nautobot and use these tabs on its detail view:

Tab	What you do there
Apps	Install custom Apps from PyPI or an uploaded package, and configure any App's settings. See Install Custom Apps.
Customization	Manage Static Files and Pip Dependencies. See Static Files and Pip Dependencies.

How It Works

In Nautobot Cloud, an instance runs from an Image — a packaged version of Nautobot core together with a set of Apps and dependencies. When you add a customization, the Console doesn't patch your running instance in place. Instead, it:

1. Stages your change against a new derived image (built on top of a Network to Code Nautobot base image).
2. Marks the instance Pending Update so you can review and batch changes.
3. When you run Update, builds the derived image automatically in your own cloud environment, then deploys it.

stateDiagram-v2
    direction LR
    Healthy --> PendingUpdate: add / change a customization
    state "Pending Update" as PendingUpdate
    state "Building Image" as BuildingImage
    PendingUpdate --> BuildingImage: Update
    BuildingImage --> Updating: build succeeds
    BuildingImage --> PendingUpdate: build fails
    Updating --> Healthy: instance starts
    Updating --> Errored: fails to start

The image build runs in your environment

The custom image is built inside your own isolated cloud account and pushed to a private container registry there. Your customizations and uploaded packages never leave your environment.

Build failures don't disrupt your instance

The image builds in the background, so your instance keeps running normally while it builds. If a build fails, its status simply returns to Pending Update — nothing about the running instance changes — so you can fix the problem and Update again.

Applying Your Changes

Every customization is staged as a pending change and takes effect only after you run Update on the instance. After you make a change, the Console prompts you with an Instance update pending dialog:

• Update Now — build the new image (you'll see a Building Image status) and deploy it.
• Update Later — keep the change staged so you can make more changes first, then apply them all with a single Update from the instance's Actions.

Because each Update triggers an image build, it's most efficient to make all of your customization changes and then run Update once. For details on the states an instance moves through, see Instance States.

If Something Goes Wrong

Your instance keeps running normally while a new image builds (the build happens in the background). If a customization doesn't succeed:

• The build fails — for example, a package or version can't be resolved. The instance returns to Pending Update without changing. Open the failed Build Image event in Event History and click See details to read the build log, correct the problem, and Update again.
• The new image builds but the instance fails to start on it — for example, a failed database migration or an app that errors on startup. The instance moves to Errored. Correct the problem and Update again to retry, or Recover it to redeploy.

A build failure leaves your instance completely untouched. A failed startup can be riskier — database migrations may have partially run — so if the data looks wrong after you recover, restore a Snapshot. Take one before any risky Update, and rehearse significant changes in a lower environment first — see Environments & Promotion. For the full lifecycle, see Instance States.

Requirements

• Your instance must be running a Nautobot 3.2.0 or higher Image. If the customization options aren't available on your instance, upgrade it to a 3.2.0+ Image first.