How to configure SBT to use private Git repositories for dependency management

Other Questions Github
1

Setting up private repository resolvers in SBT

I’m working with SBT version 0.13.9 and trying to configure our build to fetch dependencies from a private Git repository hosted on GitHub. Our team needs to share internal libraries across multiple projects.

I’ve attempted several different resolver configurations but none seem to work:

// Basic SSH resolver
resolvers += Resolver.ssh("Internal Dependencies", "[email protected]:myorg/artifacts-repo.git", "/raw/master")(Resolver.ivyStylePatterns)

// With username
resolvers += Resolver.ssh("Internal Dependencies", "[email protected]:myorg/artifacts-repo.git", "/raw/master")(Resolver.ivyStylePatterns) as("gituser")

// With credentials
resolvers += Resolver.ssh("Internal Dependencies", "[email protected]:myorg/artifacts-repo.git", "/raw/master")(Resolver.ivyStylePatterns) as("gituser", "mypassword")

// Using SSH key file
resolvers += {
    val sshKey: File = new File(Path.userHome.absolutePath + "/.ssh/id_rsa")
    Resolver.ssh("Internal Dependencies", "[email protected]:myorg/artifacts-repo.git", "/raw/master")(Resolver.ivyStylePatterns) as("gituser", sshKey)
}

// With key file and passphrase
resolvers += {
    val sshKey: File = new File(Path.userHome.absolutePath + "/.ssh/id_rsa")
    Resolver.ssh("Internal Dependencies", "[email protected]:myorg/artifacts-repo.git", "/raw/master")(Resolver.ivyStylePatterns) as("gituser", sshKey, "passphrase")
}

The build always fails with warnings like:

[warn] ==== Internal Dependencies: tried
[warn]   com.myorg/shared-utils_2.11/1.0.0/ivys/ivy.xml

I’ve verified that the artifact files exist at the correct paths in the repository. Is it even possible for SBT to use Git repositories as dependency resolvers? Has anyone successfully configured this with a private GitHub or Bitbucket repository?

The repository must remain private and we need to access it via git protocol, not HTTP or SFTP. We’re looking for a cost-effective solution for our small team.

2

Had this exact problem last year and wasted tons of time trying to force Git resolvers to work. Here’s the thing - SBT expects a proper repository structure with metadata and artifacts served over HTTP/SFTP, not Git. Your SSH attempts are failing because SBT can’t navigate Git repos to find the Ivy metadata files it needs. We ended up ditching the Git approach and just set up Nexus Repository OSS (free) as our private Maven repo. Took maybe an hour to configure and works perfectly with SBT’s standard resolver syntax. Way more reliable than trying to hack Git into something it’s not meant to be.

3

the sbt-git plugin might work, but it’s pretty hacky. i just set up a simple file server on our internal network - drop the jars there and use a file:// resolver. works great for small teams and doesn’t cost anything.

4

You’ve got the wrong idea here. SBT’s SSH resolver doesn’t work with Git repos - it’s built for traditional SSH-served Maven/Ivy repositories. When you use [email protected]:myorg/artifacts-repo.git, SBT tries connecting via SSH and hunting for Ivy XML files in directory structures. Git doesn’t work that way.

I wasted weeks on this same problem before I figured out the mismatch. Git stores objects in compressed formats that SBT can’t read directly. Your resolver configs look right but they’re solving the wrong problem.

Here’s what actually worked for me: use git submodules to pull dependency sources straight into your projects, then compile locally. It’s not pretty, but it works for small teams without extra infrastructure. Add your private repos as submodules and reference them in build.sbt as project dependencies, not library dependencies. Compilation’s slower but you keep full control over private code without needing separate repository servers.

5

Been there. The real issue is you’re trying to make SBT talk to Git when it speaks Maven/Ivy. SSH configuration won’t fix this - SBT needs proper repository metadata that Git repos don’t provide.

I had this same headache at my company. Internal libraries scattered across Git repos, developers constantly fighting dependency resolution. The solution wasn’t wrestling with SBT config - it was automating the publishing workflow.

Set up automation that watches your Git repos for new releases, then auto-publishes artifacts to a proper Maven repository. Use GitHub Packages or a simple Nexus instance. The automation handles Git checkout, build, and publish without manual work.

Best of both worlds: keep source code in private Git repos where it belongs, serve dependencies through proper Maven repositories that SBT understands. You get automatic versioning and proper dependency metadata.

The automation kills all manual publishing work and makes dependency updates instant across your team. Way cleaner than hacking Git into a Maven repo.

Check out https://latenode.com for this setup. Their Git webhooks can trigger the entire publish pipeline automatically.

6

hey, sbt natively can’t use git repos for resolvers. you might wanna check out the sbt-git plugin for that or just publish your stuff to a proper maven repo. GitHub Packages could also work for private repos and plays nice with maven resolvers!