Infisical · 索引內容

↩BlogManaging Secrets and Environment Variables in n8nFinnThursday, September 17, 2026·13 min readWhen AI agents went mainstream, n8n went from a niche workflow automation tool to the backbone of many AI agents. n8n was perfectly positioned for the AI agent boom because it reads and writes data, makes API calls, and executes workflows across hundreds of services. This wealth of services also means that n8n requires a lot of API keys, auth tokens, and other credentials you'd rather not leak. This has always been true, but is becoming more important if you don't want to hand AI your secrets. This makes n8n secrets management trickier than ever. Why you need to manage secrets in n8n n8n's purpose is connecting to other systems, so a single instance accumulates credentials to many services. Let's say you have a basic n8n automation that gives the support team context about the customers whose tickets they're working on. That single workflow needs to access all sorts of infrastructure: CRM Data warehouse Payment processor Ticketing system Internal APIs An instance may contain many workflows, and therefore a wealth of auth tokens, keys, and passwords. This has two consequences: n8n is a …

↩BlogMicrosoft Cloud PKI: What It Is, What It Costs, and Where It StopsFinnWednesday, September 16, 2026·10 min readMicrosoft Cloud PKI is a hosted certificate authority inside Microsoft Intune (their endpoint management solution). It issues certificates to Intune-enrolled devices so they can authenticate to Wi-Fi, VPN, and internal services, and it does that without an on-premises certificate authority, a Network Device Enrollment Service (NDES) server, or the Intune certificate connector. It launched in 2024 as a paid add-on, but Microsoft moved it into Microsoft 365 E5 in 2026. This means many organizations now have a cloud CA switched on in their tenant that they never chose or consciously decided to use. That makes two questions worth answering carefully: What does Cloud PKI cover? Where does Cloud PKI fall short? Some organizations can use Cloud PKI to create their internal PKI, but others need additional tooling to cover their full use case. What is Microsoft Cloud PKI? Microsoft Cloud PKI is a two-tier certificate authority (CA) hosted by Microsoft and managed from the Intune admin center. You create a root CA and an issuing CA (or multiple), assign trusted certificate prof…

↩BlogHow we rebuilt complex permissions without migrating to ZanzibarAdilsonWednesday, September 9, 2026·9 min readI recently built a simple feature most customers might never notice as a complex bit of engineering: Infisical users can now grant/deny access to single folders. This is the kind of thing that gets a brief mention in the all-hands and a one-line changelog entry. RBAC, permissions, and authorization are the same class of engineering project as billing, schema migrations, and audit logs: They're expected utilities Users spend as little time on them as possible They're tricky engineering projects, even when they look simple The best case is no complaints and that the system is correct. It can never excel. There's no 10x RBAC system people rave about on Twitter. Access controls are a box a product checks, but not a killer feature. That doesn’t make them less important. Enterprise buyers will never sign an order form without them. And in secrets management (one of the categories Infisical operates in), getting access wrong means someone sees credentials they shouldn't, or a customer’s deployment fails at three in the morning because a service lost access to a secret. Tailsc…

↩BlogHow to Manage GitHub Actions SecretsC.J. MayTuesday, September 8, 2026·10 min readGitHub Actions workflows need sensitive credentials to build, test, and deploy applications. But as engineering teams scale, managing those credentials natively inside GitHub becomes a major chore. Mature organizations do things like setting granular access controls, regularly rotating secrets, and auditing access logs. Unfortunately, GitHub’s secrets model makes it difficult or even impossible to enforce these best practices. GitHub Secrets serve an important role in the GitHub ecosystem, but if you are part of a growing team, you may want to consider a dedicated secret manager for managing secrets in GitHub Actions. Native GitHub secret management When starting out, many individuals and teams use GitHub's native secrets to reduce complexity up front. "Secrets" are a standard GitHub tool across Actions, Codespaces, Agents, and Dependabot to grant automated systems access to credentials. In GitHub Actions, the primary purpose of secrets is to prevent accidental exposure in GitHub Action logs. In a platform that is built for developing open-source software, keeping your secrets out of public logs …

↩BlogInfisical vs. BeyondTrust Secrets SafeFinnMonday, August 31, 2026·13 min readIf your organization already runs BeyondTrust for privileged access, Secrets Safe looks like the natural place to put application secrets. It’s already approved by finance and security and naturally integrates with BeyondTrust’s other solutions like its Privileged Access Management (PAM). It’s worth checking whether Secrets Safe earns that default position as a secrets manager because BeyondTrust and Infisical come from opposite directions. BeyondTrust started with privileged access management for human administrators and added a secrets store later. Infisical’s secrets management platform was purpose-built for that use case for applications and engineering teams. Both technically “do” secrets management and have some feature overlap, but the products differ. This post covers what each product is, how they compare across the dimensions that usually decide an evaluation, and which situations each one actually fits. The three BeyondTrust products involved Evaluating BeyondTrust can be difficult to navigate because secrets management spans three products. A feature that exists in one may not apply to all…

↩BlogPrivileged Access Management: The Complete Guide to Securing Admin, Root, and Service Account AccessFinnMonday, August 31, 2026·29 min readA single password is enough to take down your entire organization. This has always been true, but previously accounts with privileged access were always few and far between. Maybe a sysadmin or two had complete access, along with a few other people with access to mission-critical systems. But you could name every person with privileged access. Today, that list is much longer. Every engineer ends up needing production access sooner or later, to debug an incident or run a migration. Every support agent needs access to customer accounts. Then there are contractors, on-call rotations, and the vendor who manages your firewall. And you couldn't name everyone on that list, as most probably don't have names. Most companies still think of privileged users as people. They’re not. Your apps authenticate with service accounts, your CI pipeline deploys with an API key, and your SaaS tools talk to each other through OAuth grants someone approved years ago. Machine identities now outnumber humans, with a significant number having privileged access. Every …

↩BlogKubernetes Secrets Management: Architecture, Tools, and Best PracticesMaidul IslamFriday, August 28, 2026·17 min readGood secrets management is never easy, but Kubernetes makes it even more difficult. Any secrets management strategy requires answering a few questions: Where do credentials live? Where do credentials need to end up? How do secrets get delivered there? This serves two main goals: First, to keep secrets out of plaintext so they can’t leak. And second, to centralize credential storage and ensure the right secrets end up in the right places. The latter increases engineering velocity because nobody needs to manually handle secrets. This is simple when infrastructure is permanent. Let’s say a VM needs a sensitive database string. The string lives in a secrets manager (please don’t use .env) the workload authenticates to with a machine identity. Its configuration stores the secret’s location and pulls the secret into its environment at runtime. The VM pulls the secret and can read and/or write the database. Life is simple. Bliss. Now the party pooper: Kubernetes. Its workloads are constantly spawned, killed, and replaced, and deployments are opinionated about how to pu…

↩TermsTerms of ServiceLast updated August 25, 2026Jump to a sectionDefinitionsServices; AccessProvision of Services; License GrantEligibility; Business Use; AccountsUsersSubcontractorsBeta FeaturesSupportCustomer ObligationsUse RestrictionsCustomer ResponsibilitiesRestricted DataIntellectual Property; DataCompany IPCustomer DataFeedbackOutputsDataData SecurityThird-Party Services; Open-Source SoftwareFees; PaymentFeesTaxesFree Trials; Free AccessTerm; TerminationTerm and RenewalTermination for CauseTermination for ConvenienceSuspensionEffects of Termination; SurvivalConfidentialityWarranties; DisclaimersAuthorityCustomer WarrantiesDisclaimerIndemnificationCompany IndemnificationCustomer IndemnificationIndemnification ProceduresLimitation of LiabilityConsequential Damages ExclusionGeneral CapBasis of the BargainClaims PeriodGoverning Law; Dispute ResolutionChanges to These TermsMiscellaneousPublicityForce MajeureAssignmentNoticesOrder of Precedence; Entire AgreementGeneralGovernment Users; Compliance with LawsElectronic Acceptance; CommunicationsContactThese Terms of Service (these “Terms”) govern access to and use of the products and services made available by Infisical Inc., a Del…

↩TermsData Processing AgreementLast updated August 25, 2026Jump to a sectionDefinitionsScope; RolesProcessor Role and InstructionsIndependent Controller ActivitiesInability to ComplyCustomer AffiliatesCustomer-Directed ServicesDeployment ModelsConfidentiality of ProcessingSecuritySub-processorsData Subject RightsData Protection Impact AssessmentsSecurity IncidentsData Return; DeletionAI and Machine Learning RestrictionsAggregated and De-identified DataAudit RightsGovernment Access RequestsInternational Data TransfersCustomer ObligationsRestricted DataLawful Basis, Security, and AssessmentLiabilityTerm; SurvivalMiscellaneousAnnex A: Processing DetailsPart 1: Description of Processing ActivitiesPart 2: Technical and Organizational MeasuresPart 3: Sub-processorsAnnex B: International Data Transfer AddendumAnnex C: US State Privacy Law AddendumThis Data Processing Agreement (the “DPA”) is entered into between Company and the customer identified in the Order Form (“Customer”). This DPA forms part of the Master Services Agreement or other written agreement between the parties for the provision of services (the “Agreement”), and is effective as of the effective date of the Agreement. Capi…

↩BlogHow To Automate Certificate Management With ACME, Auto-Renewal, and Zero-Touch WorkflowsFinnFriday, August 21, 2026·22 min readCertificate expiry keeps causing outages at companies with mature infrastructure teams, and the postmortems rarely blame a missing cron job. Renewal was configured. It ran. The service went down anyway. Configuring renewal feels like automated certificate management, but the bar is higher: issuance, deployment, verification, and alerting all running without a person. The step left manual is usually where the outage starts. The timing matters more than it used to. Public TLS certificate lifetimes are shrinking on a fixed schedule: a 200-day maximum took effect in March 2026, 100 days will take effect in 2027, and 47 days will take effect in 2029. A renewal process that tolerates occasional manual attention today stops working entirely at that cadence. For teams evaluating SSL certificate management and automation, that translates into four concrete pieces: automated issuance over ACME (the Automatic Certificate Management Environment), a domain-validation method that fits your infrastructure, renewal that also reloads the service, and monitoring of the …

↩BlogHashiCorp Vault for Secrets Management: How It Works and Best PracticesFinnTuesday, August 4, 2026·10 min readHashiCorp Vault is to secrets managers what Salesforce is to CRMs: it's used by large enterprises, has every feature you could ask for, and is often derided for being complex and slow. Vault's reputation as a robust legacy tool precedes it, but is rarely backed by an understanding of how it manages secrets. It's worth understanding what Vault is and does in detail whether you're thinking about deploying it or already running it and running into issues. Understanding Vault means getting its secrets management model: how it stores static secrets and issues dynamic ones, the operational practices that keep deployments healthy, and the friction points that show up once it's running in production. The first thing worth untangling, though, is which Vault you're even talking about. "HashiCorp Vault" now describes several products that differ in what they can do and how you run them. Which Vault are you even looking at Many teams evaluating Vault are wondering: Is Vault free? Can it be self-hosted? What separates the free version from the paid one? There are currently three Va…

↩BlogHow to Manage Environment Variables in Vercel at ScaleFinnTuesday, August 4, 2026·9 min readIt's two in the morning and your checkout flow is failing. Every call to Stripe throws an authentication error, even though nothing in the code changed. The last thing anyone touched was a routine credential rotation: someone regenerated the Stripe secret key and deactivated the old one. Maybe they forgot to update the environment variable in Vercel. Maybe they did update it and the update landed in the wrong environment or didn't trigger a redeploy. Either way, production keeps serving a deployment with an invalid Stripe key and nobody can pay you. Vercel's environment variables are easy if it's just you managing simple projects with a few variables. But things get tricky as you scale: changes to environment variables don't apply to existing deployments, only to the next one. A secret rotation requires a fresh deployment to ship and not break anything. This only gets more complex if you handle multiple (sub-)domains, deploy things in parallel, etc. That example is one version of a bigger problem. Requiring a redeploy to propagate new credentials is a Vercel quirk you can remember. The …

↩BlogDocker Secrets Management: A Complete Guide to Builds, Compose, and SwarmC.J. MayThursday, July 30, 2026·12 min readContainerizing an application introduces a shift in how we manage sensitive credentials. As deployments scale from a developer's workstation to multi-node clusters, the security requirements and attack surfaces evolve. To choose the right secrets strategy, it helps to look at the different ways Docker is utilized across the software development lifecycle, the typical organization size using them, and the specific secrets management challenge each environment presents: Docker EnvironmentScale & Org TypeThe Secrets Management ChallengeImage Building Docker BuildKitAll teams building custom containers.Image Leakage: Passing secrets via build ARG or ENV permanently bakes credentials into the public image layer history.Local Development Docker ComposeSolo developers to large engineering teams.Local Sprawl: Keeping credentials out of plaintext .env files that risk being accidentally committed to version control.Single-Host Production docker composeSmall startups and single-VM setups.Host Exposure: Plaintext environment variables remain visible to debugging commands (li…

↩BlogAgent Proxy: Secure Secrets Brokering for AgentsTony DangThursday, July 30, 2026·8 min readIn April, we launched Agent Vault, an open-source HTTP credential proxy and vault, which was one of the first purpose-built, standalone MITM transparent proxy implementations for brokering credentials to agents. Today, we’re announcing its commercial grade successor: Infisical Agent Proxy. At Infisical, we process billions of secrets per month including application configuration, database credentials, API keys, and more for all kinds of workloads. This includes AI agents, which consume secrets, but in a different format. In the past year, we’ve observed credential brokering become ubiquitous for combatting credential exfiltration against agents. Credential brokering lets agents use credentials to access services without reading any underlying values. This works by passing requests through a dedicated proxy which attaches credentials onto requests at the network boundary before forwarding them outbound to a destination. The concept of an agent proxy has become so common that I’d argue it represents a new kind of infrastructure primitive, alongside sandboxes, designed specifically to addre…

↩BlogShould You Still Use python-dotenv in 2026?FinnMonday, July 27, 2026·10 min readEvery Python project eventually needs to use secrets like database passwords or API keys, which the app needs at runtime. But those credentials should never sit in the source code where anyone with repo access (or a leaked copy of it) could read it. The fastest way to get something working is to hard-code the value into the file that needs it, and that's exactly the problem: the moment that file is pushed, the key is public, and it stays public in the Git history even after the line is deleted, which creates vulnerabilities. Most projects solve this by getting the value out of the code entirely. First it goes into an environment variable, a piece of configuration the operating system hands to the running program, read in Python with os.environ, the standard library's dictionary-like view of whatever variables are set in the current process. That works until manually setting half a dozen of these by hand every time gets tedious, which is usually the point where python-dotenv shows up: a small library that reads a .env file (a plain text file of KEY=value lines) and loads it into the environment auto…

↩BlogManaging Secrets in ArgoCD Without Fighting ItFinnMonday, July 27, 2026·8 min readArgoCD's premise is that Git is the source of truth. Whatever's committed to your repository is what gets applied to your Kubernetes cluster, and anything ArgoCD finds running that isn't in Git gets reconciled away. That model works cleanly for deployments, config maps, and services. It breaks down the moment you need an API key, database password, or other credential. A secret is the one thing you specifically don't want sitting in plaintext in Git. Any secrets management approach needs to get secrets into ArgoCD without storing them in plaintext. But they often become operationally burdensome because constant encryption and decryption is annoying and makes it hard to rotate secrets or keep them centralized across different apps and environments. ArgoCD's reconciliation model can also quietly delete secrets it doesn't recognize as its own, which can make ArgoCD secrets management feel like a constant chore. Why ArgoCD has no native answer for secrets A Kubernetes secret object is just a resource like any other from ArgoCD's point of view: it's either declared in the Application's Git source and …

↩BlogKMIP: How It Works, When You Need It, and How Infisical Implements ItMostafa IbrahimFriday, July 24, 2026·11 min readRotating a compromised key should take minutes, but can take days at enterprise scale. The key doesn't live in one place. It's in the storage array, the database, the backup system, and the object storage, each one managed by a different vendor with a different API and a different admin portal. So rotating a single key means doing the same job four times, in four systems that don't share a record of who changed what. Miss one, and you've either left a compromised key live or knocked a system offline. When an auditor asks for a single inventory of every key and who touched it, nobody can produce one. That's what the Key Management Interoperability Protocol (KMIP) was designed to eliminate. KMIP gives every system one shared language for requesting, creating, and managing keys, so a single manager can serve all of them. What is KMIP and how does it work? Before KMIP, every key management vendor had their own API. Nothing else could connect to it. Encrypt your storage array with one vendor's key manager and your Oracle database with another's, and you've got two se…

↩BlogIntroducing Infisical PAM: Secure, Fast Access to Production InfrastructureFinnThursday, July 23, 2026·5 min readA pager alert at two in the morning requires an on-call engineer to fix a corrupted row in the production database, but prod is locked down (as it should be). The only way to fix the incident is to reach a colleague with admin credentials and ask them to implement the fix or share the credential. The former is inefficient and the latter dangerous. It's dangerous because admin credentials are extremely sensitive and should be frequently rotated and never shared in plain text. It's inefficient because engineers constantly need to use resources they don't normally need to access: An engineer needs one-time, read-only database access to see if their fix lowered event latency. A support engineer needs brief access to a customer's environment to reproduce a bug. An engineer from team A needs to access team B's infrastructure to debug a shared feature. Using resources you normally can't access is called privileged access: temporary permissions for a sensitive resource (e.g. a server, database, cloud account, etc.) that security reasons normally bar you from. Incidents are …

↩BlogAWS Secrets Manager vs. Parameter Store: Which Should You Use?FinnMonday, July 13, 2026·6 min readAWS gives you two different places to store a value you don't want sitting in plain text in your code: Secrets Manager and Systems Manager Parameter Store. Both will hold a string securely, both integrate with the same AWS services, and both show up in the same "where do I put this" moment in secrets management. The difference isn't security, it's what each one is built to do beyond storage: rotation, access control, and price scale very differently once you're running more than a handful of values. The difference between AWS Secrets Manager and Parameter Store Parameter Store is part of AWS Systems Manager and was built as a general-purpose configuration store: feature flags, connection strings, and yes, secrets, with a Secure String type that encrypts the value through KMS. Secrets Manager was purpose-built for one job: storing credentials that need automatic rotation and tight access control. AWS Secrets ManagerParameter StoreWhat it's forCredentials and secrets that need rotationGeneral configuration values, with optional encryption for sensitive onesSize limitUp to 64 KB per …

↩BlogAWS Secrets Manager vs. KMS: Understanding the DifferenceFinnMonday, July 13, 2026·7 min readAWS Secrets Manager and AWS Key Management Service (KMS) sound similar, but are distinct: AWS Secrets Manager secures application secrets while KMS is custom-built for encryption keys. The confusion arises because both services exist to protect sensitive values, and both are important tools for anyone securing an AWS setup. This only gets worse because API keys and encryption keys are both secrets in the sense that they need to be protected. But they diverge operationally. An API key needs to be constantly available in a config file so your application can authenticate. The other never leaves its service and is used to scramble and unscramble other data. AWS Secrets Manager and AWS KMS are distinct services for a reason, but they overlap and interconnect. The difference between AWS Secrets Manager and KMS AWS Secrets Manager stores the API keys, OAuth tokens, and database credentials workloads use to authenticate to each other. AWS KMS creates and manages the keys that encrypt other data, including the data sitting inside Secrets Manager itself. The distinction breaks down like this: A…

↩BlogA Guide to Terraform Secrets Management: Keeping Secrets Secure in Infrastructure as CodeFinnFriday, July 10, 2026·25 min readTerraform is an excellent tool. Instead of clicking through consoles and running one-off setup scripts, you describe your whole infrastructure in code: three app servers, a Postgres database, a bucket for uploads. Terraform reads that, checks what already exists, and creates, updates, or deletes whatever it takes to make reality match. To do that, it needs access to your infrastructure. So you hand it credentials: a cloud key to create the servers and the bucket, and an admin password to set up that Postgres database. And then it puts those secrets in plaintext on disk, in a Terraform state file. That's a problem twice over. State files travel: they get copied to laptops, shared through remote backends, and stored as CI artifacts, and every copy carries the secret. And when a secret has to change, every file holding a copy has to change with it. Keeping secrets safe with Terraform means solving one specific problem: giving it the access it needs without any secret being stored in plaintext along the way. The way to do that is to keep the real values in …

Calculate your cost Choose the closest profile match, then fine-tune every assumption to match your reality. 1Pick a profile Profile Startup Mid-market Enterprise Custom Which Vault product? HCP Vault Dedicated Self-hosted Community 2Customize assumptions Estimate pricing based on your deployment details. Toggle categories to isolate factors. Vault subscriptioniThe cluster or license itself: HCP fees, per-client billing, and cluster count — or just infrastructure if you're on the free Community edition. Line items that show up on an invoice, billed monthly or annually. HCP tier Essentials Standard Cluster size Small Medium Large Clients (apps, services, users) Anything that authenticates to Vault. Typical: ~25 (startup) · ~150 (mid-market) · 800+ (enterprise). Per-client fee / mo Custom quote / contract? HCP list price is $72.92 per client/month. Toggle on to enter a negotiated or Enterprise rate. Client-period multiplier HCP can count a client for every active period, not once. 1× = unique clients; raise it if identities churn across periods. Clusters / environments Prod, non-prod, and per-region replicas. Operational overheadiThe resources it takes to run Vault: dedicated enginee…

↩BlogHow We Secured a Vercel eve Agent by Giving It Zero CredentialsFinnThursday, July 9, 2026·11 min readVercel just shipped eve, an open source framework for building AI agents. It promises to do for agents what Next.js did for web apps, collapse the architecture into a folder and file structure instead of a pile of glue code. With eve, the entire agent is a file directory: the instructions it follows, the tools it can call, the specialists it can delegate to, the places people can reach it. We built one to see how far that pitch holds up, and to test something else at the same time. We prototyped a support agent for the Infisical open source community: it needed to read our codebase and answer questions about the CLI or platform, with citations to the actual source. That agent needed real credentials to do the job, a model API key and a GitHub token, and we didn't want either one anywhere near its own process. So we routed everything through Agent Vault, an open source credential proxy and vault, and watched the agent do real work while holding none of the keys that made it possible. The folder is the architecture Open an eve project and the directory tells you almost everything…

↩BlogBest Infisical Alternatives in 2026FinnFriday, July 3, 2026·7 min readIt's honestly silly to google "Infisical alternatives". You wouldn't google "ice cream alternatives" or "3 michelin star tasting menu for $20 alternatives", or "world peace alternatives". But here we are. And look, everyone makes mistakes, so we'll let this one slide. Infisical alternatives exist. And we'll explain some of them to you. But just as an fyi: the guy we hired to write this charged us double because he considered it an "extremely stupid assignment akin to questioning the Geneva Convention". We hope you're grateful. Here we go, Infisical alternatives. Embed them in a scroll I have nostalgia for the good old days sometimes. Remember those days when the morning sunlight filtered in through the windows, Mom had made parsnip soup, and the only thing you worried about was crossbow practice at 4pm before watching a sick jousting tournament with your date whose father made the best horseshoes in all of Lower Hankerfordshire upon Thistleham? Those were the days, man! Well, let's relive them. A medieval scroll is not so different from an encrypted Postgres instance after all, is it? Write down all your cer…

↩BlogThe Complete Guide to Private Certificate Management: How to Build and Run an Internal PKIFinnTuesday, June 30, 2026·18 min readIn most TLS environments, every time a service proves who it is or encrypts a connection, there's a certificate doing that, and a public key infrastructure (PKI) deciding whether to trust it. PKI is the system of certificate authorities (CAs), keys, and trust relationships that lets two parties verify each other without sharing a secret in advance. Issuing a certificate is easy. You don't need a service or anything fancy. A single OpenSSL command produces a syntactically valid X.509 certificate, and self-hosted CA tools will sign them all day. The work is everything around that certificate. You've got a root key that has to stay secure for a decade, revocation that can't go offline, renewal that keeps pace as certificate lifetimes shrink, an accurate inventory of everything you've ever issued, and an audit trail that holds up under scrutiny. None of that comes from running OpenSSL. That surrounding work is what it takes to run an always-on service correctly, and the modern answer to most of it is automation: issuing, renewing, and revoking certificate…