ARTIFACTORY: Why am I receiving a 403 error when attempting to overwrite an npm package?

Introduction

When working with npm repositories in Artifactory, you may encounter a 403 Forbidden error when attempting to publish a package that shares the same name and version as one already stored in the repository. This behavior is often unexpected, but it is in fact aligned with npm’s publishing rules. This article clarifies why the error occurs and what options are available when you need to publish updated content.

Why does Artifactory return a 403 error?

Artifactory strictly adheres to the official npm registry specifications, which are designed to ensure package immutability. According to these specifications, once a package with a specific name and version has been published, it cannot be modified or overwritten.
When a publish operation is initiated, Artifactory checks whether a package with the same name and version already exists in the target npm registry. If it does, Artifactory rejects the operation and returns a 403 Forbidden error.

 

This behavior can be observed in the artifactory-request.log, where the following type of entry appears:

2025-07-21T09:01:43.833Z|b95c61446da360d3||admin|PUT|/api/npm/davidfa-npm-local/davidfa-test|403|3106|144|12|npm/9.2.0 node/v19.4.0 darwin arm64 workspaces/false

Here, the request was blocked because the package davidfa-test with version 1.0.0 already exists under the davidfa-npm-local registry path.

Conclusion

Receiving a 403 error when publishing an npm package with an existing version in Artifactory is expected and conforms to npm's default immutability policy. To prevent this, always ensure that each new publish uses a unique version number.
Alternatively, if you need to reuse the same version, you can delete the existing package from the repository — provided you have the appropriate permissions — before re-publishing. This allows Artifactory to accept the new version without conflict.
If overwriting packages is a recurring need in your development workflow (e.g., for testing or internal CI builds), consider appending a suffix to the version (such as 1.0.0-beta.1 or 1.0.0-dev) or publishing to a dedicated scoped registry intended for non-production use.