Deploy verifiable applications in Trusted Execution Environments (TEEs)
EigenX lets you deploy containerized applications that run in secure, verifiable compute environments with built-in private key management. Your apps get a unique wallet they control, enabling autonomous onchain actions while keeping secrets safe.
- Allowlisted Account - Required to create apps. Use existing address with
eigenx auth loginor generate witheigenx auth generate. Submit an onboarding request here. - Docker - To package and publish application images (Download)
- Sepolia ETH - For deployment transactions (Google Cloud Faucet | Alchemy Faucet)
- Not recommended for customer funds - Mainnet Alpha is intended to enable developers to build, test and ship applications. We do not recommend holding significant customer funds at this stage in Mainnet Alpha.
- Developer is still trusted - Mainnet Alpha does not enable full verifiable and trustless execution. A later version will ensure developers can not upgrade code maliciously, and liveness guarantees.
- No SLA - Mainnet Alpha does not have SLAs around support, and uptime of infrastructure.
curl -fsSL https://eigenx-scripts.s3.us-east-1.amazonaws.com/install-eigenx.sh | bashcurl -fsSL https://eigenx-scripts.s3.us-east-1.amazonaws.com/install-eigenx.ps1 | powershell -# Log in to your Docker registry (required to push images)
docker login
# Log in with an existing private key
eigenx auth loginDon't have a private key? Use eigenx auth generate --store instead
Need Sepolia ETH? Run eigenx auth whoami to see your address, then get funds from Google Cloud or Alchemy
# Create your app (choose: typescript | python | golang | rust)
eigenx app create my-app typescript
cd my-app
# Configure environment variables
cp .env.example .env
# Deploy to TEE
eigenx app deployHave an existing project? You don't need eigenx app create - the CLI works with any Docker-based project:
# From your existing project directory
cd my-existing-project
# Ensure you have a Dockerfile and .env file
# The CLI will prompt for these if not found in standard locations
# Deploy directly - the CLI will detect your project
eigenx app deployWhat you need:
- Dockerfile - Must target
linux/amd64and run as root user - .env file - For environment variables (optional but recommended)
The CLI will automatically prompt for the Dockerfile and .env paths if they're not in the default locations. This means you can use eigenx with any existing containerized application without restructuring your project.
Need TLS/HTTPS? Run eigenx app configure tls to add the necessary configuration files for domain setup with private traffic termination in the TEE.
# View app information and logs
eigenx app info
eigenx app logs
# Add --watch (or -w) to continuously poll for live updates
eigenx app info --watch
eigenx app logs --watchThat's it! Your starter app is now running in a TEE with access to a MNEMONIC that only it can access.
Ready to customize? Edit your application code, update .env with any API keys you need, then run eigenx app upgrade my-app to deploy your changes
Your TEE application runs with these capabilities:
- Secure Execution - Your code runs in an Intel TDX instance with hardware-level isolation
- Auto-Generated Wallet - Access a private mnemonic via
process.env.MNEMONIC- Derive wallet accounts using standard libraries (e.g., viem’s
mnemonicToAccount(process.env.MNEMONIC)) - Only your TEE can decrypt and use this mnemonic
- Derive wallet accounts using standard libraries (e.g., viem’s
- Environment Variables - All variables from your
.envfile are available in your container- Variables with
_PUBLICsuffix are visible to users for transparency - Standard variables remain private and encrypted within the TEE
- Variables with
- Onchain Management - Your app's lifecycle is controlled via Ethereum smart contracts
# List all your apps
eigenx app list
# Stop/start your app
eigenx app stop my-app
eigenx app start my-app
# Terminate your app
eigenx app terminate my-appEigenX CLI needs a private key to sign transactions. Three options:
eigenx auth generate --store # Generate new key and store it
eigenx auth login # Store an existing key securely
eigenx auth whoami # Check authentication
eigenx auth logout # Remove keyexport PRIVATE_KEY=0x1234...
eigenx app deployeigenx app deploy --private-key 0x1234...Priority: Flag → Environment → Keyring
# Add TLS configuration to your project
eigenx app configure tls
# Add variables to .env
cat .env.example.tls >> .envRequired in .env:
DOMAIN=yourdomain.com
APP_PORT=3000Recommended for first deployment:
ENABLE_CADDY_LOGS=true # Debug logs
ACME_STAGING=true # Test certificates (avoid rate limits)Create A record pointing to instance IP:
- Type: A
- Name: yourdomain.com
- Value:
<instance-ip>(get fromeigenx app info)
eigenx app upgradeTo switch from staging to production:
# Set in .env:
ACME_STAGING=false
ACME_FORCE_ISSUE=true # Only if staging cert exists
# Deploy, then set ACME_FORCE_ISSUE=false for future deploysNotes:
- Let's Encrypt rate limit: 5 certificates/week per domain
- Test with staging certificates first to avoid rate limits
- DNS changes may take a few minutes to propagate
| Command | Description |
|---|---|
eigenx auth generate |
Generate new private key and optionally store it (aliases: gen, new) |
eigenx auth login |
Store existing private key in OS keyring |
eigenx auth whoami |
Show current authentication status and address |
eigenx auth list |
List all stored private keys by environment |
eigenx auth logout |
Remove private key from OS keyring |
| Command | Description |
|---|---|
eigenx app create [name] [language] |
Create new project from template |
eigenx app configure tls |
Add TLS configuration to your project |
eigenx app name <app-id|name> <new-name> |
Set a friendly name for your app |
| Command | Description |
|---|---|
eigenx app deploy [image_ref] |
Deploy new app to TEE |
eigenx app upgrade <app-id|name> <image_ref> |
Update existing deployment |
| Command | Description |
|---|---|
eigenx app start [app-id|name] |
Start stopped app |
eigenx app stop [app-id|name] |
Stop running app |
eigenx app terminate [app-id|name] |
Permanently remove app |
| Command | Description |
|---|---|
eigenx app list |
List all your deployed apps |
eigenx app info [app-id|name] |
Show detailed app information |
eigenx app logs [app-id|name] |
View application logs |
Watch Mode: Add --watch (or -w) to info or logs commands to continuously poll for updates
| Command | Description |
|---|---|
eigenx environment show |
Show active deployment environment (alias: env) |
eigenx environment list |
List available deployment environments |
eigenx environment set <environment> |
Set deployment environment |
| Command | Description |
|---|---|
eigenx telemetry [--enable|--disable|--status] |
Manage usage analytics |
eigenx upgrade |
Update CLI to latest version |
eigenx version |
Show CLI version |
If you prefer to build and push Docker images yourself instead of letting the CLI handle it, or already have an existing image:
# Build and push your image manually
docker build --platform linux/amd64 -t myregistry/myapp:v1.0 .
docker push myregistry/myapp:v1.0
# Deploy using the image reference
eigenx app deploy myregistry/myapp:v1.0Requirements:
- Image must target
linux/amd64architecture - Application must run as root user (TEE requirement)
EigenX collects anonymous usage data to help us improve the CLI and understand how it's being used. This telemetry is enabled by default but can be easily disabled.
- Commands used (e.g.,
eigenx app create,eigenx app deploy) - Error counts and types to identify common issues
- Performance metrics (command execution times)
- System information (OS, architecture)
- Deployment environment (e.g., sepolia, mainnet-alpha)
- User Ethereum address
- Personal information or identifiers
- Private keys or sensitive credentials
- Application source code or configurations
- Specific file paths or project names
# Check current telemetry status
eigenx telemetry --status
# Disable telemetry
eigenx telemetry --disable
# Re-enable telemetry
eigenx telemetry --enableTelemetry settings are stored globally and persist across all projects.
For a detailed understanding of how EigenX enables verifiable applications with deterministic identities, see our Architecture Documentation.
- Hardware Isolation - Intel TDX secure enclaves with memory encryption
- Attestation - Cryptographic proof of exact Docker image integrity
- Deterministic Keys - Apps receive consistent identities via KMS
- Smart Contracts - Onchain configuration and lifecycle management
Build from source:
git clone https://github.com/Layr-Labs/eigenx-cli
cd eigenx-cli
make build # Builds for development (default)
GO_TAGS=prod make build # Builds for production
./bin/eigenx --helpRun tests:
make tests # Full test suite
make tests-fast # Quick tests onlyFor testing template changes locally without pushing to GitHub:
- Clone the templates repository:
git clone https://github.com/Layr-Labs/eigenx-templates- Use local templates with environment variables:
# From the eigenx-cli directory or one level above
EIGENX_USE_LOCAL_TEMPLATES=true ./bin/eigenx app create test-app typescript
# Or specify the path explicitly
EIGENX_TEMPLATES_PATH=/path/to/eigenx-templates EIGENX_USE_LOCAL_TEMPLATES=true eigenx app create test-app golangThis uses templates from your local eigenx-templates/ directory instead of fetching from GitHub.
For in-depth understanding of EigenX concepts, see EIGENX_CONCEPTS.md:
- Keys - Auth keys vs TEE mnemonics, storage locations, and security model
- Environment Variables - Encryption, public variables, and KMS security
- App Lifecycle - States, transitions, and lifecycle flow diagram
- Privacy - What's private, what's public, and privacy guarantees
- Security Best Practices - Do's and don'ts for secure TEE development
- Threat Model - What TEE/KMS protects against and security boundaries
For testing new features before production:
# Tag with dev suffix and incremental build number
git tag v0.1.0-dev.1
git push origin v0.1.0-dev.1
# Found a bug? Increment the build number
git tag v0.1.0-dev.2
git push origin v0.1.0-dev.2This deploys to the dev environment and can be installed with:
curl -fsSL https://eigenx-scripts.s3.us-east-1.amazonaws.com/install-eigenx.sh | bash -s -- --devAfter testing in dev, promote to production:
# Promotes the latest v0.1.0-dev.* version to production
git tag v0.1.0
git push origin v0.1.0This:
- Verifies a dev version exists (e.g.,
v0.1.0-dev.2) - Copies the exact same binary from dev to production
- Creates a GitHub release
- Updates the stable installation channel
Users get the promoted version with:
curl -fsSL https://eigenx-scripts.s3.us-east-1.amazonaws.com/install-eigenx.sh | bash- Build once: Same binary promoted from dev to prod
- Safety: Cannot release untested code to production
- Coexistence:
eigenx-devandeigenxcan both be installed - Clean versions: Production gets clean version numbers (v0.1.0)
- Easy rollback: Tag any previous version for instant rollback
- Development:
--devflag installs aseigenx-dev - Production: Default installation installs as
eigenx
Both versions can coexist on the same system.
🚧 eigenx-cli is in alpha, under active development, and has not been audited.
- Features may be added, removed, or modified
- Interfaces will have breaking changes
- Should be used only for testing purposes and not in production
- Provided "as is" without guarantee of functionality or production support
Eigen Labs, Inc. does not provide support for production use.
If you discover a vulnerability, please do not open an issue. Instead contact the maintainers directly at security@eigenlabs.org.