Introduction
When provisioning a JFrog project and project-scoped Artifactory repositories (for example, local and virtual repositories) with Terraform, terraform plan can succeed while terraform apply fails with an HTTP 404 and a message such as “Could not find project <project_key>” on the repository resource even if the project resource just reported creation complete.
Root cause:
-
Terraform parallelism and implicit dependencies
Terraform may execute independent operations concurrently. Repository creation calls can start before the project is consistently usable for project-scoped repository management APIs.
-
String literals hide dependencies
If repository resources set project_key using a hard-coded string (for example, project_key = "my-project") instead of referencing the project resource, Terraform may not infer a dependency on that project resource. That increases the risk of out-of-order creates.
-
Ordering sensitivity / eventual consistency
Even with correct references, some environments benefit from explicit depends_on to serialize provisioning (typically project → first repository → dependent repositories) to avoid brief 404 windows immediately after project creation.
Resolution
Follow these steps to ensure Terraform applies are aligned with how Artifactory expects project-scoped resources to be created.
Step 1: Reference the project resource, not only a string
Use the project resource’s key output so Terraform knows the repository belongs to that project in the graph.
project_key = project.<name>.key (or equivalent attribute your provider exposes)
Avoid (for dependency purposes):
project_key = "test" as the only link to the project, because it may not create an
implicit dependency on project.test.
Step 2: Add explicit depends_on on the local (or first) repository
After the project resource, force repository creation to wait on the project.
Example pattern:
resource "artifactory_local_pypi_repository" "example_local" {
key = "example-pypi-local"
project_key = project.test.key
depends_on = [project.test]
}
Step 3: Chain dependencies for the virtual repository
Ensure the virtual repository is created after the local repository (and still after the project).
Example pattern:
resource "artifactory_virtual_pypi_repository" "example_virtual" {
key = "example-pypi-virtual"
project_key = project.test.key
repositories = [
artifactory_local_pypi_repository.example_local.key,
"shared-internal-pypi-virtual",
]
depends_on = [
project.test,
artifactory_local_pypi_repository.example_local,
]
}Adjust resource types and keys to match your module.
Step 4: (Optional) Explicit repository sharing across projects
If the organization uses project_share_repository (or equivalent) to formally attach a shared repository to a target project, we can add it when your standards require it. It can clarify ownership and access patterns.
Step 5: Re-run plan and apply
Run terraform plan and confirm the dependency order reflects: project → local repo → virtual repo (and any optional share in the right place).
Run terraform apply.
If issues persist, capture provider versions, full error text, and whether project_key literals remain anywhere in the same apply.
Conclusion
The 404 “Could not find project” error during repository creation is typically a Terraform dependency and apply-ordering issue, not a sign that auto-share is ineffective. Fix it by binding project_key to the project resource and using depends_on, so repositories are created only after the project (and after any prerequisite repos in the same apply). Optional project_share_repository may still be valuable for cross-project sharing governance, but it is often not required to resolve this specific failure once ordering is correct.