> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/troubleshooting-and-resources/knowledge-base-article/understanding-artifact-sources-in-nextgen.md).

# Artifact sources in NextGen

Compare FirstGen and NextGen artifact source behavior, sorting, and performance guidance in Harness Continuous Delivery

Artifact sources let you manage application dependencies in Harness Continuous Delivery. This topic explains how artifact sources behave in NextGen, how that differs from FirstGen, and how sorting and performance work when you select versions and tags.

***

## What you will learn from this topic

* How [FirstGen artifact sources](#firstgen-artifact-sources) differed from the NextGen model
* How [NextGen runtime fields and on-demand loading](#nextgen-artifact-sources) change configuration and tag selection
* How [sorting and ordering](#sorting-and-ordering) work across artifact server types
* How to apply [performance optimizations](#performance-optimizations) for large tag sets

***

## Before you begin

* **Artifact sources on a service**: Familiarity with attaching artifact sources to a Harness service helps. Go to [Artifact sources](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/artifact-sources.md) to review supported sources and UI limits.

***

## FirstGen artifact sources

FirstGen offered a foundational approach to artifact management with these limitations:

* **Rigid configurations**: Artifact sources were static and required separate configurations for similar images. This led to redundancy and configuration overload.
* **Stale data**: Artifact collection in FirstGen cached data, which could show outdated information and cause deployment errors.
* **Unnecessary polling**: Constant polling of all configured sources, regardless of usage, wasted resources and overloaded artifact servers.
* **Limited tag management**: You could not enter specific versions or tags directly, which made large lists harder to manage.

***

## NextGen artifact sources

NextGen uses a dynamic model for artifact management:

* **Runtime fields**: Every field in an artifact source can be dynamic, so you can configure values with variables and expressions. This simplifies complex deployments.
* **On-demand loading**: Versions and tags load only when needed, which avoids outdated cached lists and shows the latest information.
* **Smart access**: NextGen accesses artifact sources when you interact with them, instead of polling unused sources continuously.
* **Direct version and tag input**: You can enter any version or tag, even when it is not listed, which streamlines selection.

***

## Sorting and ordering

Sorting behavior differs between FirstGen and NextGen.

* **FirstGen**: Versions were primarily sorted by the time they were pushed to the artifact server (Docker registry, Artifactory, and similar). That ordering depended on artifact collection.
* **NextGen**: Sorting differs by artifact type:
  * **Supported servers**: If the artifact server supports sorting, NextGen uses that sorting for display.
  * **Limited support**: For servers without built-in sorting, NextGen fetches and sorts all versions and tags on the client side.
  * **Timestamp limitations**: Servers such as Docker registries lack timestamp support, so NextGen uses lexicographic sorting. That can look inconsistent when tags are Git commit IDs or a similar strategy.

Go to [Artifact limits and display in the Harness UI](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/artifact-sources.md#artifact-limits-and-display-in-the-harness-ui) to review order and limits for each artifact source in NextGen.

***

## Performance optimizations

The following conditions can affect NextGen performance when you browse or select artifacts:

* **Server capabilities**: Limited search, filter, or sort support on some artifact servers can force client-side sorting and slow the UI.
* **Large tag sets**: Extensive tag lists (more than 10,000) can slow loading because of API pagination.

Use the following practices to improve performance:

* **Predictable tagging**: Use semantic versioning and a predictable tagging strategy, such as appending the build number or timestamp, so version order stays clear. If you use Harness Continuous Integration (CI), you can use the pipeline execution sequence ID for consistent sorting.
* **Archiving old tags**: Regularly archive outdated versions and tags to keep the list manageable.
* **Contact support**: For specific server limitations, contact [Harness Support](mailto:support@harness.io) for assistance.

***

## Next steps

* [Artifact sources](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/artifact-sources.md): Configure supported artifact sources and review UI ordering limits.
* [Triggered pipeline fails while manual execution succeeds](/continuous-delivery/troubleshooting-and-resources/knowledge-base-article/triggered-pipeline-fails.md): Fix triggers that omit artifact source inputs.

{% @harness-feedback/feedback %}