home / skills / steveclarke / dotfiles / env-to-fnox

env-to-fnox skill

/ai/skills/env-to-fnox

This skill guides migrating secrets from .env to fnox with 1Password, enabling centralized management and secure automation.

npx playbooks add skill steveclarke/dotfiles --skill env-to-fnox

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.3 KB
---
name: env-to-fnox
description: This skill should be used when users want to migrate from .env files to fnox with 1Password (or another secret provider). It covers installing fnox, creating 1Password items, configuring fnox.toml, and integrating with mise. Use when users mention ".env migration", "fnox setup", "1password secrets", or want to improve their secret management workflow.
---

# Migrate from .env to fnox + 1Password

This skill guides the migration from plaintext `.env` files to fnox with 1Password as the secret provider. fnox is provider-agnostic and supports multiple backends (1Password, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, age encryption, etc.).

## Prerequisites

Before starting, verify:
1. 1Password CLI is installed: `op --version`
2. User is authenticated to 1Password: `op vault list`
3. mise is installed (optional but recommended): `mise --version`

## Migration Workflow

### Step 1: Analyze Existing .env

Read the existing `.env` file to understand what secrets need migration:

```bash
cat .env
```

Categorize the secrets:
- **Cloud provider credentials** (AWS_*, ARM_*, GOOGLE_*)
- **API tokens** (CLOUDFLARE_*, GITHUB_*, etc.)
- **Application secrets** (DATABASE_URL, API_KEY, etc.)
- **Configuration values** (non-secret defaults like regions)

### Step 2: Install fnox

Install fnox via mise (recommended):

```bash
mise use fnox
```

Or add to `mise.toml`:

```toml
[tools]
fnox = "latest"
```

Initialize fnox configuration:

```bash
mise exec -- fnox init
mise exec -- fnox provider add op 1password
```

### Step 3: Create 1Password Item

Create a single 1Password item containing all secrets. Use the API Credential category for organization:

```bash
op item create \
  --category="API Credential" \
  --title="project-name" \
  --vault="Private" \
  'Field Name[text]=value' \
  'Secret Field[password]=secret-value'
```

Field naming conventions:
- Use descriptive names: "AWS Access Key ID" not "aws_key"
- Use `[text]` for non-sensitive values (IDs, regions, emails)
- Use `[password]` for sensitive values (secrets, tokens, keys)

Example for a typical project:

```bash
op item create \
  --category="API Credential" \
  --title="myproject" \
  --vault="Private" \
  'AWS Access Key ID[text]=AKIA...' \
  'AWS Secret Access Key[password]=...' \
  'Database URL[password]=postgres://...' \
  'API Token[password]=...'
```

### Step 4: Configure fnox.toml

Update `fnox.toml` to reference the 1Password item:

```toml
[providers.op]
type = "1password"
vault = "Private"

[secrets]
# Format: ENV_VAR = { provider = "op", value = "item-title/Field Name" }
AWS_ACCESS_KEY_ID = { provider = "op", value = "myproject/AWS Access Key ID" }
AWS_SECRET_ACCESS_KEY = { provider = "op", value = "myproject/AWS Secret Access Key" }
DATABASE_URL = { provider = "op", value = "myproject/Database URL" }

# Non-secret defaults don't need 1Password
AWS_DEFAULT_REGION = { default = "us-east-1" }
```

### Step 5: Integrate with mise

Update `mise.toml` to use fnox instead of `.env`:

```toml
[tools]
fnox = "latest"
# ... other tools

[env]
_.source = "fnox export"
```

Remove the old `.env` reference:
```diff
- _.file = ".env"
+ _.source = "fnox export"
```

### Step 6: Verify and Clean Up

Test the configuration:

```bash
# List configured secrets
mise exec -- fnox list

# Verify a secret can be retrieved
mise exec -- fnox get AWS_ACCESS_KEY_ID

# Test full environment
mise exec -- printenv | grep AWS_
```

Once verified, delete the old `.env` file:

```bash
rm .env
```

Commit `fnox.toml` (it contains no secrets, only references):

```bash
git add fnox.toml mise.toml
git commit -m "Migrate secrets from .env to fnox + 1Password"
```

## fnox.toml Reference

### Provider Configuration

```toml
# 1Password
[providers.op]
type = "1password"
vault = "Private"
# account = "my.1password.com"  # Optional: specify account

# Age encryption (for git-stored encrypted secrets)
[providers.age]
type = "age"
recipients = ["age1..."]

# AWS Secrets Manager
[providers.aws]
type = "aws-sm"
region = "us-east-1"
prefix = "myapp/"
```

### Secret Reference Formats

```toml
[secrets]
# 1Password: item-title/field-name
SECRET = { provider = "op", value = "myproject/Secret Field" }

# 1Password: full op:// URI
SECRET = { provider = "op", value = "op://Vault/Item/Field" }

# Default value (no provider needed)
REGION = { default = "us-east-1" }

# Age-encrypted value
SECRET = { provider = "age", value = "YWdlLWVu..." }
```

### Profiles for Multiple Environments

```toml
[providers.op]
type = "1password"
vault = "Development"

[secrets]
DATABASE_URL = { provider = "op", value = "dev-db/url" }

[profiles.production.providers.op]
vault = "Production"

[profiles.production.secrets]
DATABASE_URL = { provider = "op", value = "prod-db/url" }
```

Use profiles with: `FNOX_PROFILE=production fnox export`

## Troubleshooting

### "No configuration file found"
Run `fnox init` to create `fnox.toml`, or check that you're in the correct directory.

### 1Password authentication errors
Ensure you're signed in: `op signin` or check that "Integrate with other apps" is enabled in 1Password Settings > Developer.

### Secrets not loading in shell
If using mise, ensure `mise trust` has been run for the project directory.

### fnox command not found after mise install
Use `mise exec -- fnox` or restart your shell to pick up the new PATH.

Overview

This skill guides migrating plaintext .env files to fnox with 1Password (or another secret provider) to centralize and secure secrets. It covers installing fnox, creating organized 1Password items, authoring fnox.toml, and integrating fnox with mise for consistent environments across machines. The goal is to remove .env files, keep secret values out of git, and make environment provisioning reproducible.

How this skill works

The skill inspects your existing .env keys and classifies them into secrets, credentials, and non-secret defaults. It shows how to install and initialize fnox (recommended via mise), create a single 1Password item with named fields, and map those fields to environment variables in fnox.toml. Finally it replaces mise .env sourcing with fnox export and verifies secret retrieval and runtime environment values.

When to use it

  • You plan a .env migration to a secret backend like 1Password
  • You need a reproducible, git-safe environment setup across multiple machines
  • You want to centralize API keys, DB URLs, and cloud credentials
  • You are onboarding mise and want secrets managed consistently
  • You need provider-agnostic secret references (1Password, AWS SM, age, etc.)

Best practices

  • Group related secrets into a single 1Password item using descriptive field names
  • Use [password] type for sensitive fields and [text] for IDs/defaults
  • Keep fnox.toml in git; it stores references, not secret values
  • Use mise to install and run fnox for consistent tooling across machines
  • Verify retrieval with mise exec -- fnox get and test the full env before deleting .env

Example use cases

  • Migrate a web app’s DATABASE_URL, API_TOKEN, and AWS_* keys from .env into 1Password and fnox.toml
  • Configure separate fnox profiles (development, production) pointing to different 1Password vaults
  • Adopt age encryption for secrets stored in git while using fnox to reference them
  • Standardize environment setup for a team so each developer runs mise and gets the same secrets
  • Replace hardcoded secrets in CI by switching build jobs to run fnox export

FAQ

Do I need 1Password to use fnox?

No. fnox is provider-agnostic and supports 1Password, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, age, and others. This skill focuses on 1Password as an example.

What parts of the repo change and what gets committed?

Commit fnox.toml and mise.toml changes. fnox.toml contains only secret references and provider configuration. Do not commit any exported secrets or the old .env file after migration.