What is the difference between configuration and secrets?

Configuration is non-sensitive app behavior data, like feature flags or environment names. Secrets are sensitive values such as API keys, database passwords, and signing keys that must be protected separately.

Why should SaaS teams separate secrets from configuration?

Separation reduces accidental exposure in code repositories, makes access control clearer, and simplifies audit evidence for security and compliance reviews.

What tools are commonly used for secret management?

Teams often use cloud secret managers or dedicated vault systems, plus CI/CD integrations and short-lived credentials. The right choice depends on your architecture, risk profile, and operational maturity.

Does separating secrets guarantee ISO certification?

No. It helps with ISO readiness and control implementation, but certification depends on the full management system, evidence, and a successful external audit.

How can APLINDO help with this topic?

APLINDO supports SaaS engineering, applied AI, Fractional CTO advisory, and ISO/compliance consulting for teams in Indonesia and globally. We can help design practical secret and configuration controls without overengineering.

Indonesia SaaS Secrets: Separate Config Safely

Time information: This article was automatically generated on June 10, 2026 at 9:21 AM (Asia/Jakarta, 2026-06-10T02:21:20.925Z).

Why secret separation matters in SaaS

For Indonesian SaaS teams, separating secrets from configuration is one of the fastest ways to reduce operational risk without slowing delivery. It sounds simple, but many incidents start with a password in a .env file, an API key in a Git repo, or a production token copied into a staging script. Once that happens, the problem is no longer just technical; it becomes a compliance, audit, and trust issue.

In practice, configuration tells an application how to behave, while secrets prove identity or grant access. If you treat both the same way, you create unnecessary exposure. If you separate them cleanly, you make it easier to rotate credentials, restrict access, and show evidence during ISO readiness reviews.

What should count as configuration vs secrets?

A useful rule is this: if the value can be safely shared with the engineering team or stored in a normal config file, it is configuration. If exposure would create a security incident, it is a secret.

Examples of configuration:

Environment names such as dev, staging, or prod
Feature flags
Public base URLs
Non-sensitive timeouts and thresholds
Logging levels

Examples of secrets:

Database usernames and passwords
API keys for payment, messaging, or AI services
JWT signing keys
OAuth client secrets
Encryption keys
Webhook verification secrets

This distinction matters in Jakarta-based startups and enterprise environments alike. A public cloud deployment in Singapore, a private cluster in Indonesia, or a hybrid setup across both still needs the same discipline: keep sensitive material out of places where it can be copied too easily.

What goes wrong when teams mix them?

The most common failure mode is convenience. A developer adds a secret to a config file because it is faster, then later that file is committed to Git, shared in Slack, or copied into a deployment template. Another common issue is environment sprawl: the same secret gets reused across dev, staging, and production because nobody wants to reconfigure each service manually.

When secrets and configuration are mixed, teams usually face four problems:

Accidental exposure: secrets show up in repositories, logs, or screenshots.
Weak access control: too many people can read values they do not need.
Slow rotation: changing one secret requires editing many files and redeploying blindly.
Poor auditability: it becomes difficult to prove who accessed what and when.

For compliance teams, this creates friction during internal reviews. For engineering teams, it creates fear of change. Both are avoidable.

A practical separation model for Indonesia SaaS teams

A good baseline is to split the system into three layers.

1. Application configuration in code or config files

Store non-sensitive settings in version control. This includes feature flags, service endpoints, and runtime options. Use environment-specific overlays if needed, but keep the values non-secret.

2. Secrets in a dedicated secret manager

Store sensitive values in a secret manager, not in application code. Common patterns include cloud-native secret stores, vault-style systems, or managed KMS-backed solutions. The important part is not the brand name; it is the control model.

3. Delivery through runtime injection

Inject secrets at runtime through your CI/CD pipeline, container orchestrator, or application startup process. The app should read the secret only when needed and avoid printing it to logs.

This model works well for funded startups that want speed and for enterprises that need governance. It also fits remote-first teams like APLINDO’s operating model, where access must be controlled across distributed engineers and contractors.

How does this support ISO readiness?

Separating secrets from configuration helps with several common control areas in ISO-oriented programs, especially around access control, information security, and change management. It does not guarantee certification, but it creates cleaner evidence.

Auditors and internal assessors often look for:

A documented policy for secret handling
Restricted access based on role
Evidence of secret storage outside source control
Rotation procedures for exposed or expired credentials
Logs showing access and changes
Review of environment-specific configuration

If your team uses one process for all environments, you can usually explain it clearly. If your team has a different process for production, that is fine too, as long as the controls are deliberate and documented.

For companies in Indonesia pursuing ISO readiness, this is especially useful because it reduces the amount of manual explanation needed during audits. A clear architecture diagram and a few well-maintained procedures often go further than a large policy document nobody follows.

What should your CI/CD pipeline do?

Your pipeline should help enforce the separation, not weaken it. A healthy pipeline usually does the following:

Pulls secrets from a trusted secret manager at deploy time
Masks sensitive values in logs
Prevents secrets from being stored in build artifacts
Fails builds if secret scanning detects leaked credentials
Uses short-lived credentials where possible
Limits production access to approved roles only

If your pipeline still relies on long-lived .env files being copied around manually, that is a sign to simplify. Manual handling is where mistakes happen.

How APLINDO approaches this in real projects

At APLINDO, we usually start with the business risk, not the tool. A FinTech SaaS in Jakarta may need stronger controls around payment keys and audit trails. A B2B platform serving overseas clients may care more about separation across regions, role-based access, and evidence for enterprise procurement. A compliance-heavy product may need both engineering changes and policy updates.

Our SaaS engineering and ISO/compliance consulting work often focuses on practical steps such as:

Defining what counts as a secret in the current system
Mapping secret flow from development to production
Removing secrets from repositories and build logs
Designing access controls for engineers and operators
Creating audit-friendly procedures without overengineering

If needed, we also help teams align this work with broader platform decisions, including applied AI workloads, self-hosted products like SealRoute, or compliance workflows in Patuh.ai.

Key takeaways

Secrets and configuration are not the same thing, and they should not be stored the same way.
Keep non-sensitive config in version control and store secrets in a dedicated secret manager.
Runtime injection, access control, and logging discipline make audits easier and deployments safer.
This pattern supports ISO readiness, but it does not guarantee certification or legal outcomes.
For Jakarta and Indonesia SaaS teams, clear separation reduces risk without slowing product delivery.

What is the simplest next step?

Start by inventorying every secret in your stack. Look at repositories, CI variables, deployment manifests, shared docs, and chat history. Then classify each item as configuration or secret. Move the sensitive values out of source control, restrict access, and document the new flow.

If your team is preparing for an audit or wants a second opinion on the design, bring in a professional reviewer. The goal is not perfection on day one. The goal is to make secret handling boring, repeatable, and easy to prove.