# Architect: declarative AWS serverless apps from a plaintext manifest

> Architect (the arc CLI) turns a small manifest file into API Gateway, Lambda, DynamoDB and S3 resources, with a local sandbox for offline work. It is aimed at JavaScript and Python teams who want AWS serverless infrastructure without writing CloudFormation by hand.

**architect/architect** — The simplest, most powerful way to build a functional web app (fwa)

- Repository: https://github.com/architect/architect
- Website: https://arc.codes
- Stars: 2,626 · Forks: 107
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/architect-architect

## What problem Architect solves, and for whom

Provisioning a serverless backend on AWS by hand means writing CloudFormation or Terraform for API Gateway routes, Lambda functions, DynamoDB tables, S3 buckets and the IAM policies that connect them. Architect replaces that with a manifest: a small file that declares what the app needs, from which the CLI derives the underlying AWS resources. The README frames the goal as building "ultra scalable database backed web apps on AWS serverless infrastructure with full local, offline workflows." The audience is narrow and specific. You are deploying to AWS, not to a neutral runtime. Your functions are written in Node.js, Python or Ruby, with Java, .NET, Golang and Lambda runtime layers listed as additional options. If your team already knows Lambda and API Gateway but resents hand-writing their configuration, that is the gap this fills. If you are shopping for a portable function platform, it is the wrong starting point.

## How the arc CLI turns a manifest into AWS resources

The published package, @architect/architect, is a thin command layer over a set of separate modules. Its dependencies include @architect/create, @architect/deploy, @architect/destroy, @architect/env, @architect/hydrate, @architect/inventory, @architect/logs and @architect/sandbox, each pinned to its own major version. That split explains the behaviour you see from the outside. The inventory module reads the manifest and resolves it into a description of the app. The sandbox module runs that description locally. The deploy module takes the same description and creates the corresponding AWS resources. The hydrate step is where function dependencies are installed and bundled before they ship. Because the CLI is a dispatcher rather than a monolith, the version of each submodule matters when you debug a deploy. The bin entry is src/index.js, so `npx arc` invokes that file, and the package declares `engines.node` as `>=22` in package.json even though the README's Requirements section states Node.js 18 or newer for the Architect runtime. That discrepancy between the README and the manifest is worth knowing before you pick a Node version for CI.

## Installing Architect and running a first app locally

The README's installation path assumes Node.js is already present. Install the CLI as a development dependency so it stays out of your production bundle:

```bash
npm i @architect/architect --save-dev
```

Then confirm the binary resolves and reports a version:

```bash
npx arc version
```

The README notes that running `arc` with no arguments prints help, which is the fastest way to see the available subcommands. To start a project, create a directory and initialise it:

```bash
mkdir testapp
cd testapp
npx arc init
```

The init step writes the manifest and starter function files into the directory. From there, the local development server is a single command:

```bash
npx arc sandbox
```

According to the README, `Cmd / Ctrl + c` exits the sandbox. The sandbox is the part that matters most for day-to-day work: it lets you exercise routes and data access without touching AWS, which is why the project describes its workflows as local and offline. Deployment uses the same manifest. `npx arc deploy` ships a staging stack, `npx arc deploy --production` ships to production, and the README notes that additional staging stacks can be created with `--name`.

## Where Architect stops being the right tool

The clearest limitation is provider lock-in. Every module in the dependency list is oriented toward AWS: API Gateway, Lambda, DynamoDB, S3 and SNS appear in the package keywords, and the deployment target is an AWS account. There is no documented path to running the same manifest on another cloud. A second constraint is runtime support. The README lists Node.js, Python and Ruby as function runtimes with package managers npm, yarn, pip3 and bundle, and treats Java, .NET, Golang and runtime layers as optional extras. If your services are written in a language outside that set, the manifest will not describe them. The third issue is release cadence. The most recent releases listed are v5.8.6 and 5.8.6, both dated 2019-05-15, while package.json in the repository declares version 12.0.1. The repository was last pushed on 2026-09-05 and is not archived, so work continues, but the published release history does not reflect it. Anyone who pins a version or watches a release feed should treat that gap as a real operational fact rather than a cosmetic one.

## Architect compared with writing CloudFormation directly

The obvious alternative is authoring the AWS resources yourself in CloudFormation, or in a general infrastructure-as-code tool that emits it. The difference is where the abstraction sits. With CloudFormation you describe resources: a function, an API, a table, and the permissions between them. With Architect you describe the app and let the CLI derive those resources from the manifest. That is a genuine trade. The manifest is shorter and stays readable as the app grows, and the sandbox gives you a local loop that raw CloudFormation does not provide. In exchange, you give up direct control over the generated template. When you need a resource type the manifest does not express, or a policy the CLI does not emit, you are working against the tool rather than with it. CloudFormation also lets you target any AWS service without waiting for framework support. Architect's own documentation lives at https://arc.codes, and the README points there for the full picture; that is the place to check whether a specific resource is expressible before you commit to the manifest approach.

## Maintenance, upgrade cost and the Apache-2.0 licence

Architect is licensed under Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not impose copyleft obligations on your application code. That is the permissive end of the spectrum, and for most teams it removes licence review as a blocker. The upgrade story is less tidy. The CLI delegates to eight @architect packages, each independently versioned, and the repository's package.json pins them at specific majors while the README's requirements section and the package's own engines field disagree about the minimum Node version. Upgrading the top-level package therefore pulls a coordinated set of submodule changes, and a failure can originate in any of them. The repository ships a changelog.md at the top level, which is where to look before bumping. Budget for testing the sandbox and a staging deploy after each upgrade, not just a version bump in package.json. The last push to the repository was on 2026-09-05.

## Conclusion

Adopt Architect if your team is comfortable on AWS, writes JavaScript or Python functions, and wants the infrastructure layer described in a file that lives beside the code. Do not adopt it if you need a provider-neutral deployment target, or if you cannot tolerate a CLI whose published release history stops in 2019 while the repository continues to receive commits. Before committing, verify three things yourself: that Node.js 18 or newer is available in your build environment, that `npx arc init` produces the project layout you expect, and that `npx arc deploy` against a scratch AWS account creates the stack you intended. The manifest is the contract; read it before you deploy.

## FAQ

### What is Architect (arc) and what does it do?

Architect is a CLI, published as @architect/architect, that creates, deploys and maintains AWS cloud function infrastructure from a manifest file. The README describes it as a way to build database backed web apps on AWS serverless infrastructure with local, offline workflows.

### How do I install Architect?

Install it as a development dependency with npm i @architect/architect --save-dev, then check it with npx arc version. The README requires Node.js 18 or newer for the Architect runtime, while package.json declares engines.node as >=22.

### How do I run an Architect app locally before deploying?

After npx arc init creates the project, run npx arc sandbox to start the local dev server. The README states that Cmd / Ctrl + c exits the sandbox.

### How do I deploy an Architect app to AWS?

Run npx arc deploy for a staging stack, or npx arc deploy --production to ship to production. The README notes that additional staging stacks can be created with --name.

### Which languages can Architect functions be written in?

The README lists Node.js, Python and Ruby as function runtimes, with npm, yarn, pip3 and bundle as the corresponding package managers. Java, .NET, Golang and Lambda runtime layers are listed as additional optional runtimes.

## Sources

- [architect/architect on GitHub](https://github.com/architect/architect)
- [License: Apache-2.0](https://github.com/architect/architect/blob/main/LICENSE)
- [Project website](https://arc.codes)
- [README](https://github.com/architect/architect/blob/main/README.md)
- [Releases](https://github.com/architect/architect/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/architect-architect