A co-signer is a program in your environment that signs transactions automatically. It uses a service account, a device key, and an encrypted key share. By default, the key share stays encrypted until Utila's Secure Enclave decrypts it for signing.
Use secret managers for your credentials
The service account private key (or a cloud KMS key that holds it) should be kept in a secrets manager, such as AWS Secrets Manager or GCP Secret Manager, and injected into the instance or container running the co-signer as an environment variable at runtime.
The device key and the encrypted key share are different. They live in a co-signer state, not as environment variables. In production, encrypt that state using AWS KMS or GCP KMS.
Whichever cloud you use, avoid storing any of these secrets in git, in container images, or on unencrypted disks.
Ports
The co-signer does not need any inbound ports open, since it only makes outbound connections.
For outbound traffic, open port 443 (HTTPS) to:
The Utila API
The Utila Secure Enclave
If you store your co-signer state or keys in the cloud, also allow outbound access to that KMS, S3, or storage endpoint.
If you run the co-signer in webhook mode, it makes outbound calls to your webhook, so an inbound port is only needed on your webhook service, not on the co-signer host itself.
Access management
Apply strict IAM policies (or the GCP equivalent) to the instance or container role running the co-signer, limiting it to only the secrets, keys, and storage it actually needs.
Avoid attaching broader admin roles.
It's also good practice to run the co-signer on a dedicated host or container, and limit who can log into it.