Infrastructure provisioning

Overview

All shyware deployments share a common signing infrastructure layout. The Terraform modules live in ShywareLLC/core/infra/ (the community server repo — github.com/ShywareLLC/core). Per-deployment configuration is a thin terragrunt.hcl wrapper — no per-deployment Go or Terraform code required.

Module layout

ShywareLLC/core/infra/
  kms/          — AWS KMS validator key + tally key + a scoped IAM instance
                  profile (validator_role) for the validator EC2 instance
  signing/      — thin wrapper around kms/, outputs threaded into validator/
  validator/    — AWS EC2 instance + security group + Cloudflare tunnel
                  (hostile-regime deployments)

As of this module's current version, the validator targets AWS EC2, not Hetzner, with a scoped IAM instance profile rather than IAM Roles Anywhere — see the "Validator auth" section below for why, and read that section before assuming either Hetzner or IAM Roles Anywhere for a new deployment. If your deployment genuinely needs non-US compute jurisdiction (unlike a purely cost-driven choice), that's a real constraint this module doesn't currently serve — check ShywareLLC/core/infra/validator/main.tf's own header comment for the current guidance before assuming this module covers it.

Each deployment's deploy/ directory contains only the Terragrunt wrapper:

<deployment>/deploy/
  signing/
    terragrunt.hcl    — points to ShywareLLC/core/infra/signing; passes project/namespace inputs
  validator/
    terragrunt.hcl    — points to ShywareLLC/core/infra/validator; reads signing outputs automatically

Shared remote state

# terragrunt.hcl (repo root)
remote_state {
  backend = "s3"
  config = {
    bucket         = "shyware-tfstate"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "shyware-tfstate-locks"
    encrypt        = true
  }
}

Provisioning a deployment

Every deployment follows the same two-step sequence:

Step 1 — signing

cd <deployment>/deploy/signing
AWS_ACCOUNT_ID=<account> terragrunt apply

This creates:

AWS KMS ECC_NIST_P256 validator signing key
AWS KMS ECC_NIST_P256 tally signing key
A scoped IAM instance profile (validator_role) — sign-only on the two keys above, X-Ray write, CloudWatch Logs/Metrics scoped to the project

Outputs: kms_validator_key_id, kms_tally_key_id, instance_profile_name, validator_role_arn

Copy kms_tally_key_id into shyconfig.json (or inject via SHYWARE_* environment variables) — no ARN/trust-anchor copying needed for auth, since the instance profile attaches directly in Step 2.

Step 2 — validator (hostile-regime deployments only)

cd <deployment>/deploy/validator
AWS_VPC_ID=<vpc> AWS_SUBNET_ID=<subnet> AWS_SSH_PUBLIC_KEY=<key> \
CLOUDFLARE_TUNNEL_TOKEN=<token> CLOUDFLARE_WARP_TOKEN=<token> \
terragrunt apply

Signing outputs (including the instance profile name) are threaded in automatically via the dependency block — no manual ARN copying required.

Deployment signing configs

Contract version	Posture	Notes
`shyvoting-v1`	`recoverable`	Civic voting — domestic deployment
`shyvoting-v1`	`coercion_resistant`	Hostile-regime — validator in neutral jurisdiction
`shyshares-v1`	`recoverable`	DAO or consortium governance
`shywire-v1`	`recoverable`	Anonymous value transfer
`shycontracts-v1`	`recoverable`	Anonymous smart contracts

Validator auth: an IAM instance profile, not IAM Roles Anywhere

An earlier version of this module used IAM Roles Anywhere — an ACM Private CA issuing the validator an X.509 certificate at boot, exchanged for a 1-hour STS session token. That design was replaced: the ACM Private CA alone costs roughly $400/month regardless of usage, and it was never actually load-bearing — the real signing code resolves credentials via the standard AWS SDK credential chain and has no Roles Anywhere / STS-exchange logic at all, so the PCA machinery was solving a problem the code didn't have.

Since the validator now runs on AWS EC2 itself (compute and KMS/ADOT are the same cloud), there's no cross-cloud credential problem to solve either: the validator gets a plain IAM instance profile, which supplies temporary, auto-rotating credentials via the EC2 instance metadata service with zero key material on disk, for zero additional cost — strictly simpler than both the Roles Anywhere design and a static access key would have been. The instance profile's policy restricts kms:Sign to the specific key ARNs this module provisions, the same least-privilege scoping Roles Anywhere provided.

If a deployment's compute genuinely can't be AWS (a real jurisdiction requirement, not just a cost preference), this module doesn't cover that case as currently written — see ShywareLLC/core/infra/validator/main.tf's own comment for pointers to the prior Hetzner-targeted variant.

Starting the node

After provisioning, start the ABCI node with the unified binary:

shyware-abci \
  --config  shyconfig.json \
  --db-path /opt/<deployment>/data \
  --addr    :26658

The binary reads all configuration — identity provider, governance keys, signing key IDs, deployment posture — from shyconfig.json. REDACTED values are injected via SHYWARE_* environment variables at runtime.

See Go SDK — protocol/config for the config.Load() and config.Manifest reference.

Overview​

Module layout​

Shared remote state​

Provisioning a deployment​

Step 1 — signing​

Step 2 — validator (hostile-regime deployments only)​

Deployment signing configs​

Validator auth: an IAM instance profile, not IAM Roles Anywhere​

Starting the node​