If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/apex/up shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 7 active contributors
• MIT licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live apex/up repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/apex/up.

What it runs against: a local clone of apex/up — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in apex/up | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 813 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of apex/up. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/apex/up.git
#   cd up
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of apex/up and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "apex/up(\\.git)?\\b" \\
  && ok "origin remote is apex/up" \\
  || miss "origin remote is not apex/up (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "cmd/up/main.go" \\
  && ok "cmd/up/main.go" \\
  || miss "missing critical file: cmd/up/main.go"
test -f "config/config.go" \\
  && ok "config/config.go" \\
  || miss "missing critical file: config/config.go"
test -f "handler/handler.go" \\
  && ok "handler/handler.go" \\
  || miss "missing critical file: handler/handler.go"
test -f "cmd/up-proxy/main.go" \\
  && ok "cmd/up-proxy/main.go" \\
  || miss "missing critical file: cmd/up-proxy/main.go"
test -f "config/runtimes.go" \\
  && ok "config/runtimes.go" \\
  || miss "missing critical file: config/runtimes.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 813 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~783d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/apex/up"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Up is a serverless deployment tool that packages vanilla HTTP applications (Node.js, Go, Python, Java, etc.) and deploys them to AWS Lambda + API Gateway in seconds with zero infrastructure management. It handles packaging, routing, environment configuration, and scaling automatically, providing a Heroku-like developer experience on top of AWS Lambda's cost-effective compute. Monolithic CLI tool structure: cmd/up contains the main CLI entrypoint, cmd/up-proxy is the Lambda proxy handler, config/ package handles all .up.json parsing and validation with 20+ specialized config types. The Go module approach keeps everything as a single deployment binary with embedded runtime detection in config/runtimes.go.

Full-stack developers and DevOps engineers who want to deploy production applications without managing servers or orchestration, particularly those building REST APIs, static websites, and microservices who already have AWS credentials and want a CLI-first workflow.

Production-ready and actively maintained. The codebase is substantial (~380KB Go), has comprehensive test coverage across config parsing and deployment logic, includes CI/CD pipeline configuration (.goreleaser.yml), and professional documentation structure (docs/ folder with 9 guides). The tool has been battle-tested in production across multiple runtime environments.

Moderate risk due to AWS SDK dependency chain (aws/aws-sdk-go with 40+ transitive dependencies listed) and tight coupling to AWS Lambda/API Gateway APIs. The project shows signs of slower activity (last update likely pre-2020 based on module versions), and maintenance responsibility appears concentrated. Breaking changes risk comes from AWS service updates that may not be immediately reflected.

No recent activity visible in the provided metadata, but the repo appears to maintain stable releases via .goreleaser.yml configuration for automated binary distribution across platforms.

Clone the repo: git clone https://github.com/apex/up.git && cd up. Install dependencies: go mod download. Build the CLI: make build or go build -o bin/up ./cmd/up. The Makefile contains build targets for multiple platforms.

Daily commands: Development: make build compiles the up binary to bin/up. For testing config parsing: go test ./config. The Makefile defines standard targets; inspect it for full command list. To deploy a test app, create an app.js/app.go, then ./bin/up in that directory (requires valid AWS credentials in environment).

• cmd/up/main.go — Entry point for the Up CLI tool; all deployment commands originate here
• config/config.go — Core configuration schema and parsing; defines all up.json settings that drive deployment behavior
• handler/handler.go — HTTP request handler and runtime logic; processes Lambda events and routes to user applications
• cmd/up-proxy/main.go — Proxy server that sits between API Gateway and the user's HTTP application
• config/runtimes.go — Runtime detection and initialization for Node.js, Python, Go, Java, Crystal, Clojure; critical for multi-language support
• http/cors/cors.go — CORS middleware implementation; handles cross-origin request configuration from up.json
• http/errorpages/errorpages.go — Custom error page rendering engine; transforms 4xx/5xx errors into templated responses

• handler.go (Go, AWS Lambda Runtime API) — Receives Lambda events, spawns up-proxy, translates responses, enforces timeouts
  • Failure mode: If handler crashes, entire Lambda invocation fails; no retry within same execution
• up-proxy binary (Go net/http, JSON marshaling) — Converts Lambda event (headers, body, path, method) to HTTP request; forwards to user app; reads response
  • Failure mode: If proxy crashes or hangs, Lambda receives timeout error; user app isolation preserved
• config package — undefined

Add support for a new runtime language

1. Define runtime detection and bootstrap in config/runtimes.go (config/runtimes.go)
2. Add runtime-specific handler logic (e.g., Node.js bin/launcher vs Python launcher) in handler/handler.go (handler/handler.go)
3. Add documentation for the new runtime in docs/05-runtimes.md with example up.json (docs/05-runtimes.md)
4. Create testdata directory with example app and up.json in handler/testdata/{language}/ (handler/testdata/node/up.json)

Add a new HTTP middleware feature (e.g., rate limiting, auth)

1. Create middleware package in http/{feature}/ directory with main implementation (http/cors/cors.go)
2. Add configuration schema to config/{feature}.go (config/cors.go)
3. Integrate middleware into handler/handler.go request processing chain (handler/handler.go)
4. Document configuration options in docs/04-configuration.md (docs/04-configuration.md)

Add a new deployment or environment configuration option

1. Add field to appropriate config struct in config/{feature}.go (config/config.go)
2. Add test cases for parsing the new field in config/{feature}_test.go (config/config_test.go)
3. Document the option in docs/04-configuration.md with example yaml (docs/04-configuration.md)

• AWS Lambda + API Gateway — Serverless compute and HTTP routing without managing infrastructure; pay-per-invocation model aligns with cost savings pitch
• Go language for CLI & proxy — Single binary cross-platform distribution; fast startup for Lambda cold-start sensitive use case; easy CLI tooling
• Multi-runtime support (Node, Python, Go, Java, Crystal, Clojure) — Allows developers to use existing frameworks and codebases without rewriting; reduces adoption friction
• up-proxy sidecar process — Decouples user's HTTP server from Lambda event format; enables any vanilla HTTP server to run unmodified

• Proxy pattern (up-proxy) instead of direct Lambda integration

  • Why: Allows vanilla HTTP apps to run without modification; supports any framework
  • Consequence: Adds ~10-50ms latency and IPC overhead per request; complexity of subprocess management

• Single Go binary for CLI instead of per-language SDKs

  • Why: Consistent UX across all runtimes; easy distribution; single source of truth for deployment logic
  • Consequence: Go-specific toolchain required; less idiomatic for Python/Node developers

• Configuration via up.json (YAML/JSON) instead of code-based config

  • Why: Lower learning curve; declarative and version-controllable; DevOps-friendly
  • Consequence: Less runtime flexibility; users must commit and redeploy for config changes

• Custom error page templating instead of delegating to user code

  • Why: Centralized error handling across all runtimes; consistent UX
  • Consequence: Limited customization; users cannot hook error handling logic in their code

• Does not handle user authentication or authorization; relies on AWS IAM and API Gateway auth
• Does not provide a managed database or persistent storage layer; relies on AWS RDS, DynamoDB, S3
• Does not support real-time features like WebSockets natively (Lambda's API Gateway integration has limits)
• Does not handle CI/CD pipeline orchestration; assumes users manage git hooks or external CI systems
• Does not provide multi-cloud support; AWS Lambda and API Gateway are hard dependencies

AWS credentials must be configured before running (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY or IAM role). The tool requires valid AWS account and IAM permissions for Lambda, API Gateway, CloudFormation, and potentially S3, CloudFront, Route53 depending on deployment type. The .up.json config file is required in the project root—missing it will fail. Environment variable encryption requires Up Pro subscription, the free version stores them plaintext in Lambda.

• Lambda function bundling and packaging — Up's core responsibility is transpiling vanilla HTTP frameworks into AWS Lambda-compatible function packages; understanding how runtimes are auto-detected and bundled is essential to extending language support
• API Gateway proxy integration — Up uses API Gateway's proxy mode to forward HTTP requests to Lambda; the up-proxy handler converts Lambda events back to HTTP, a pattern that determines how request routing works
• CloudFormation infrastructure-as-code — Up generates CloudFormation templates to manage API Gateway, Lambda functions, DNS records, and SSL certificates; understanding the template structure is key to debugging deployment issues
• Environment variable encryption and rotation — The config/environment.go module handles plaintext vars in OSS and encrypted vars in Pro tier; understanding the crypto strategy clarifies the free vs. paid feature boundary
• Custom DNS and certificate provisioning — config/dns.go orchestrates Route53 DNS updates and ACM certificate provisioning; essential for understanding how custom domains are wired to the deployed API
• Backoff and retry strategies — config/backoff.go implements exponential backoff for API calls; understanding this is critical for diagnosing intermittent deployment failures and timeouts
• Static asset CDN distribution — config/static.go handles automatic CloudFront CDN setup for static files; the caching and invalidation strategy directly impacts site performance and cost

• serverless/serverless — Competing serverless framework supporting multi-cloud deployment; uses similar Lambda abstraction but with plugin architecture instead of opinionated config
• aws-amplify/amplify-cli — AWS-native alternative providing full-stack app deployment including backend + frontend; more feature-rich but requires AWS Amplify categories
• apex/apex — Predecessor project by same author focusing on AWS Lambda function deployment at lower abstraction level without HTTP server assumption

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for config package parsers

The config/ directory has multiple parsing modules (duration.go, errorpages.go, hooks.go, lambda.go, stages.go, static.go, relay.go, runtimes.go) but many lack corresponding _test.go files. Given that config parsing is critical for deployment correctness, adding tests for missing parsers (relay.go, runtimes.go, doc.go, environment.go, cors.go, logs.go) would prevent silent failures in user deployments.

• [ ] Create config/relay_test.go with tests for relay configuration parsing
• [ ] Create config/runtimes_test.go with tests for runtime detection and validation
• [ ] Create config/environment_test.go with tests for environment variable parsing
• [ ] Add edge case tests (empty configs, invalid values, type coercion)
• [ ] Ensure >80% code coverage for config package

Add handler tests for all supported runtimes in handler/testdata

The handler/testdata directory contains test fixtures for node, node-pkg, node-pkg-start, and spa, but handler/handler_test.go likely doesn't comprehensively test all runtime variants. Python, Golang, Java, Crystal, and Clojure are advertised as supported but lack testdata fixtures. Adding minimal testdata fixtures and corresponding integration tests would ensure these runtimes remain functional across refactors.

• [ ] Create handler/testdata/python with a simple WSGI app and up.json
• [ ] Create handler/testdata/golang with a net/http server and up.json
• [ ] Create handler/testdata/static with sample HTML/CSS/JS files and up.json
• [ ] Expand handler/handler_test.go to test each testdata fixture variant
• [ ] Verify handler correctly routes requests to each runtime's entry point

Add missing GitHub Actions workflow for Go linting and cross-platform builds

The repo has .goreleaser.yml for releases but .github/workflows/ appears to lack CI automation. Given the project is Go-based with .github/ISSUE_TEMPLATE.md and .github/PULL_REQUEST_TEMPLATE.md already in place, adding a GitHub Actions workflow for linting (golangci-lint), testing (go test), and validating cross-platform builds would catch regressions early and enforce code quality on PRs.

• [ ] Create .github/workflows/ci.yml with job for go vet, go test, and golangci-lint
• [ ] Add build matrix testing for linux/amd64, darwin/amd64, windows/amd64
• [ ] Include go.mod/go.sum validation to catch dependency drift
• [ ] Configure workflow to run on pull_request and push to main branch
• [ ] Add status badge to README.md

• Add test coverage for config/cors.go and config/relay.go (both exist but lack corresponding *_test.go files, visible in file list)
• Expand docs/05-runtimes.md with concrete examples for Python and Java deployments (currently has minimal guidance compared to Node.js/Go)
• Implement missing error page documentation in docs/ linking to config/errorpages.go functionality with custom error handler examples

• High · Outdated AWS SDK Dependency — go.mod - github.com/aws/aws-sdk-go v1.31.9. The go.mod file specifies github.com/aws/aws-sdk-go v1.31.9, which is significantly outdated (released in 2020). This version likely contains known security vulnerabilities and missing patches for AWS service interactions. Fix: Update to the latest stable version of aws-sdk-go (v2.x recommended). Run 'go get -u github.com/aws/aws-sdk-go' and test thoroughly.
• High · Multiple Outdated Indirect Dependencies — go.mod - indirect dependencies section. Several indirect dependencies marked with '// indirect' are from 2016-2017 era and lack security patches. Examples include github.com/golang/sync, github.com/alecthomas/* packages, and compression libraries (dsnet/compress). These pose supply chain security risks. Fix: Run 'go mod tidy' and 'go mod verify'. Review and update all transitive dependencies. Consider using 'go list -m all' to audit the full dependency tree.
• Medium · Unverified Third-Party Dependencies — go.mod - various indirect dependencies. Dependencies like github.com/dchest/uniuri and github.com/facebookgo/freeport lack recent maintenance history visible in the versions specified. No integrity verification method is evident in the codebase. Fix: Ensure go.sum file is committed and tracked. Use 'go mod verify' regularly. Consider using a dependency scanning tool like 'go list -json' with trivy or govulncheck.
• Medium · Potential Credential Exposure via CLI Tool — cmd/up/main.go, cmd/up-proxy/main.go. The project includes cmd/up/main.go which is a CLI tool deployed to AWS Lambda. CLI tools handling AWS credentials require careful management to prevent credential exposure in logs, temporary files, or Lambda function outputs. Fix: Audit credential handling in CLI code. Ensure AWS credentials are not logged, printed to stdout, or stored in Lambda environment without encryption. Use AWS Secrets Manager or parameter store for sensitive data.
• Medium · Static Content Serving Without Security Headers — handler/handler.go, config/ directory. The handler package serves static content (handler/testdata/static) without visible security header configuration. No Content-Security-Policy, X-Frame-Options, or other security headers visible in file structure. Fix: Add security headers middleware in handler.go for all responses. Implement CSP, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, and X-XSS-Protection headers.
• Medium · CORS Configuration Without Apparent Validation — config/cors.go. config/cors.go exists but its implementation details are not visible. CORS misconfiguration could allow cross-origin attacks if origins are not properly validated. Fix: Review cors.go to ensure: 1) Origin whitelist is used (not '*'), 2) Credentials are not sent to untrusted origins, 3) Methods are explicitly allowed, 4) Headers are validated.
• Medium · Lambda Deployment Without Visible Security Controls — config/lambda.go, cmd/up/main.go. The codebase deploys to AWS Lambda but no visible implementation of: VPC configuration, environment variable encryption, IAM role scope limiting, or request validation before Lambda invocation. Fix: Implement: 1) Minimal IAM policies for Lambda execution, 2) Environment variable encryption using KMS, 3) VPC configuration if accessing internal resources, 4) Input validation before Lambda invocation.
• Low · Test Data with Hardcoded Configuration — handler/testdata/*/up.json. Handler testdata directories contain multiple up.json configuration files with test data that could reveal configuration patterns or sensitivities if accidentally exposed. Fix: Ensure testdata directories are excluded from production builds. Add .gitignore rules to prevent accidental commit of sensitive test configurations.
• Low · Missing HTTPS Enforcement Configuration — undefined. No visible explicit HTTPS- Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.