I've seen this happen in almost every mid-sized Scala project I've joined: a developer creates an application.conf file, puts the production database password and the Stripe API key right in there, and then adds application.conf to the .gitignore file. They feel secure because the secrets aren't in the git history. They think they've "solved" secrets management.

The '.gitignore' Safety Net is Enough

Here is why that approach is a ticking time bomb. First, it creates a "manual deployment" nightmare. Since the config isn't in git, some poor DevOps engineer (or you, at 3 AM) has to manually SSH into a production server to SCP a text file into the right folder. It's brittle and doesn't scale to Kubernetes or AWS ECS. Second, and more dangerously, it leads to "secret sprawl." That file exists in plain text on a developer's laptop, on a backup server, and in the memory dump of the JVM. If a teammate accidentally removes that line from .gitignore for just one commit, your production credentials are now immortalized in your git history forever.

Injecting Secrets via Environment and Dedicated Vaults

The correct way to handle this is to decouple your configuration (how the app behaves) from your secrets (how the app authenticates). Configuration can live in git; secrets must never touch it.

The baseline for any professional Scala app is using environment variables. Instead of hardcoding a password, your HOCON file should look like this:

db.password = ${?DATABASE_PASSWORD}

The ${?VAR} syntax in HOCON tells Typesafe Config: "Use this environment variable if it exists; otherwise, don't crash, just leave it unset." This allows you to keep your app portable. But for high-security environments, environment variables aren't enough—they can be leaked via phpinfo() style dumps or process listing tools. That's where a dedicated Secret Manager (like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault) comes in.

Type-Safe Secrets with Ciris

I generally avoid using the raw Typesafe Config library for secrets because it returns strings or options, forcing you to pepper your code with .getOrElse or risky .get calls. I prefer Ciris. It's a library designed specifically for configuration loading that treats "missing secrets" as a first-class error during application startup, rather than a NullPointerException ten minutes after the app has booted.

Here is how I typically structure a secrets loader for a production service connecting to a database and a payment gateway:

import ciris._
import cats.effect._
import cats.implicits._

case class AppConfig(dbPassword: String, stripeKey: String)

object ConfigLoader {
  val load: IO[AppConfig] = {
    val dbPass = env("DATABASE_PASSWORD")
    val stripeKey = env("STRIPE_API_KEY")

    // We combine these using a Map (Applicative) 
    // so we get ALL missing secrets in one error message, 
    // not just the first one that fails.
    (dbPass, stripeKey).mapN(AppConfig.apply)
  }.load
}

By doing this, your application will fail to start immediately if the environment is misconfigured. I'd much rather have a pod crash-loop in Kubernetes with a clear "Missing STRIPE_API_KEY" error than have the app start up and fail only when the first customer tries to check out.

📋 Practical Task

Build a Secure Database Credential Resolver

You are tasked with replacing a hardcoded password in a legacy Scala service. Instead of reading from a file, you must implement a resolver that attempts to load the database password from an environment variable, but falls back to a "Development" mock password only if a specific flag ENV=dev is set.

• Create a case class DbConfig(password: String).
• Use the Ciris library (or standard sys.env if you prefer, though Ciris is recommended) to implement the logic.
• The logic must be:
  • If ENV is "prod" and DB_PASSWORD is missing, the application must fail to start with a descriptive error.
  • If ENV is "dev", it should use "dev_password_123" if DB_PASSWORD is not provided.
• Write a main method that prints "Connected with password: [password]" on success, or the specific error message on failure.