---
title: Signing in Production
description:
  Where signing keys live in a production Solana application, and how to choose
  between local keys, browser wallets, cloud KMS/HSM, and managed signing
  backends.
type: conceptual
prerequisites:
  - /docs/core/transactions/transaction-structure
related:
  - /docs/tools/keychain
  - /docs/payments/production-readiness
---

A transaction only executes if it carries a valid
[signature](/docs/core/transactions/transaction-structure#signatures) from every
required signer. During local development you usually hold that key as a
[`Keypair`](/developers/cookbook/wallets/create-keypair) and sign directly. In
production the important question is different: **where does the private key
live, and who is allowed to authorize a signature with it?**

<Callout type="warn">
  Never embed private keys in client-side code, bundle them into a frontend, or
  commit them to source control. Anyone who obtains a key gains full control of
  that account's funds.
</Callout>

## Signing approaches

| Approach                  | Where the key lives                                     | Who signs                                          | Best for                                                      |
| ------------------------- | ------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------- |
| **Local keypair**         | A file or environment variable on the machine           | Your code, directly                                | Local development, tests, CI                                  |
| **Browser wallet**        | The end user's wallet (e.g. Phantom, Solflare)          | The end user, per transaction                      | Frontend dApps where users sign their own transactions        |
| **Cloud KMS / HSM**       | A hardware-backed key service (AWS KMS, GCP KMS, Vault) | Your backend requests a signature from the service | Backend services, treasury operations, regulated environments |
| **Managed / MPC wallets** | Split or custodied across a provider's infrastructure   | The provider co-signs according to your policy     | Embedded wallets, approval workflows, institutional custody   |

The local keypair is the only approach that puts raw key material inside your
application. Every production approach keeps the key in dedicated infrastructure
and asks that infrastructure to sign on your behalf.

## Backend signing

When a server needs to sign — paying fees, sending program transactions, or
operating a treasury — use a dedicated key-management backend rather than a raw
keypair. The Solana Foundation maintains [Keychain](/docs/tools/keychain), a
unified signing library (Rust and TypeScript) that exposes one `SolanaSigner`
interface across every backend in the table above: Memory, HashiCorp Vault, AWS
KMS, GCP KMS, Fireblocks, Privy, Turnkey, CDP, Crossmint, Dfns, Para, Openfort,
and Utila.

Because the interface is identical across backends, you can develop locally with
an in-memory key and switch to a production backend through configuration,
without rewriting application code. Keychain is compatible with
[`@solana/kit`](/docs/clients/official/javascript) and the
[Rust SDK](/docs/clients/official/rust).

<Cards>
  <Card title="Keychain" href="/docs/tools/keychain">
    Unified signing across local keys, KMS, HSM, and managed wallet backends.
  </Card>
  <Card
    title="Choosing a backend"
    href="/docs/tools/keychain/choosing-a-backend"
  >
    Compare custody models and pick the right signing backend for your app.
  </Card>
</Cards>

For the full production checklist — key management, RPC security, and monitoring
— see [Production Readiness](/docs/payments/production-readiness).