# Streetmix: designing a street cross-section with the public

> Streetmix is a TypeScript web application that lets communities and planners design a street cross-section together, by assembling lanes, sidewalks, trees and street furniture and remixing each other's designs. It grew out of a Code for America hackathon and is built on Node with npm workspaces, Sequelize, Vitest and Cypress.

**streetmix/streetmix** — Streetmix makes it easy for people to design public spaces together.

- Repository: https://github.com/streetmix/streetmix
- Website: https://streetmix.net
- Stars: 749 · Forks: 217
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/streetmix-streetmix

## What a street section is and why the app is built around it

Streetmix is a collaborative process for communities and city planners to improve public spaces. You design, remix and share a neighbourhood street at streetmix.net.

The core object is the section, which the README explains at length as a shortened way of saying cross-section view, a type of 2D non-perspectival drawing commonly used in engineering and architecture to show what something looks like when you take a slice of it and look at it head-on. A street section is a cross section view of a street, showing the widths and placement of vehicle lanes, bike lanes, sidewalks, trees and street furniture such as benches or street lamps, along with engineering information like how the road is sloped to facilitate drainage and where the underground utilities are.

The important nuance is that urban designers and architects who work in public space have created very colourful illustrative street sections, removing most of the engineering particulars to communicate how a street could be designed to feel safe, walkable or habitable. So the drawing is deliberately simplified. The README's own example image shows three of them side by side, an existing conditions section of Market Street from the Better Market Street Plan in San Francisco, a proposed one-way cycletrack design of Second Street from the Great Second Street Plan, and an illustrative section.

That simplification is the product. A section is a communication artefact, not a construction document, and Streetmix is a tool for producing and arguing over one.

## The engagement problem Streetmix was built to solve

The why section describes a specific professional practice and its limits.

When city planners seek input from the public on streetscape improvements at community meetings, one common engagement activity is to create paper cut-outs depicting different street components, like bike lanes, sidewalks and trees, and let attendees reassemble them into their desired streetscape. Planners and city officials can then take that feedback to determine a course of action for future plans.

Streetmix is the web version of that activity, and the stated benefit is reach: planners can reach a wider audience than they could at meetings alone, and community members can share and remix each other's creations.

The second goal is two-way communication. Streetmix intends to communicate not just feedback to planners but also information and consequences of actions to the people creating the streets, and the README compares it to SimCity and its in-game advisors. That is a real design commitment, since a tool that only collects votes cannot tell anyone whether the street they designed would work, and the more a public understands about the consequences of a curb position or a lane width, the more useful their input becomes.

The intended uses are engagement around streetscape and placemaking issues, and the README links two frameworks for that, Complete Streets from the National Complete Streets Coalition and the Project for Public Spaces' Rightsizing Streets Guide.

The project started as a Code for America hackathon project in January 2013, inspired by the community meetings described above. The name is the obvious one, streets plus remix.

## The stack and the npm workspace layout

Streetmix is a Node.js based project, and the package.json describes a modern single-repository setup.

The engines field asks for Node at 22.21.0 or later, or 24.10.0, or 26.0.0, with npm at 11 or later, and the package is marked as type module, so the code is ESM throughout.

The workspaces array is the interesting part, because it shows the project has been decomposed into shared packages.

```json
    "packages/types",
    "packages/utils",
    "packages/i18n",
    "packages/parts",
    "packages/*",
    "client",
    "docs"
```

There are named packages for types, utilities, internationalisation and the street parts themselves, alongside a catch-all packages/* entry for the rest, and then the client and docs directories as workspaces of their own. A packages/parts package is the natural place for the definition of every lane, sidewalk and street furniture type, which means the vocabulary of the drawing is shared code rather than duplicated in the client.

The scripts show how the development loop works. The start script runs three things concurrently, a development server, a development client and a TypeScript build in watch mode.

```json
    "start": "concurrently --names \"SERVER,CLIENT,TSC\" \"npm:dev-server\" \"npm:dev-client\" \"npm:dev-tsc\"",
```

The server is run through nodemon with the New Relic agent loaded in the serve script, and the development variant uses node with the .env file loaded through the --env-file-if-exists flag. The client is built by the workspace script npm run -w @streetmix/client dev, so the client really is a separate package with its own toolchain.

## Running the tests and the database migrations

The test setup is layered, with unit tests, type checking and end-to-end tests all present.

The top level test script runs the linters and then the unit tests together.

```json
    "test": "npm run lint && npm run vitest",
```

Linting is split in two, a CSS pass through stylelint over the client stylesheets and a JavaScript pass through eslint.

```json
    "lint:js": "eslint",
```

The unit tests run under Vitest, with a project-scoped variant for the server, a coverage variant used in CI, and a config file at the root named vitest.config.ts. End-to-end coverage is Cypress, with an open mode for interactive debugging and a run mode for automation.

```json
    "vitest:ci": "vitest run --coverage",
    "cypress:run": "cypress run",
```

The database is Sequelize, and the migrations are driven by the standard Sequelize CLI.

```json
    "db:migrate": "npx sequelize-cli db:migrate",
```

There is a matching undo script, db:migrate:undo, and a .sequelizerc file at the root, so the CLI configuration is checked in rather than passed on every invocation.

Coverage is tracked through Codecov, with a codecov.yml at the root and a badge in the README, and the CI workflow badge points at a GitHub Actions workflow. Translations are managed as a script too, with a download step that reads the .env file and a CI variant that does not, pointing at the i18n package's download_translations script, and Transifex appearing in the environment configuration.

## Configuration, authentication and the optional services

The .env.example file is a good map of what the application talks to, and the file is unusually well commented.

The required secrets are the three Auth0 values.

```bash
NODE_ENV=development
AUTH0_DOMAIN=
AUTH0_CLIENT_ID=
AUTH0_CLIENT_SECRET=
```

The header explains the convention: rename the file from .env.example to .env to use it, and once renamed it is ignored by Git and should never be committed.

The server configuration is commented out rather than required, and covers the application domain, the protocol and the port. The optional secrets section is a long list of third-party integrations, each commented. Cloudinary for media, Facebook for social login, New Relic for monitoring, Patreon for the funding link with its client id, secret and webhook secret, Pelias for geocoding with a default host of api.geocode.earth, Carto for mapping, Plausible for analytics, Transifex for translations, Web Monetization for payments and Userback for feedback.

The database configuration is optional too, with the standard PostgreSQL variables and a DATABASE_URL, and the additional configuration block at the end covers the cookie session secret, a debug flag, an offline mode, an instance name and a sponsor banner.

That last one, OFFLINE_MODE, is worth noting for anyone running a private instance, since a self-hosted deployment that can talk to Pelias and Carto is a deployment that is sending queries about its users' street designs to third parties, and turning that off is a decision the configuration makes available.

## Where Streetmix is the wrong choice

The first limitation is the drawing's purpose, and it is stated in the README. A section is a communication artefact with most of the engineering particulars removed, so a Streetmix design is not something you can hand to a contractor. A project that needs geometric compliance, levels, drainage calculations or utility coordination needs a different tool, and the app is honest about that in the description of what a section is.

The second is the dependency surface. The .env.example lists Auth0 as required and then a dozen optional services, each of which is an account, an API key and a failure mode. A small city deploying this for a single engagement is signing up for Auth0, and quite possibly for Pelias, Cloudinary, Transifex and Patreon, whether or not they use them. A self-hosted instance that sets OFFLINE_MODE and leaves the rest blank is a smaller commitment, but it is also a different product from the hosted one.

The third is that the browser does the drawing, so the result lives in a web page. The README does not describe exporting a section as a drawing file for a report, and the artifacts in the repository are the app, the client and the documentation. A planner who needs a printable section in a PDF is not the primary user here, and the model is a shared link rather than a deliverable.

The fourth is the release history. The published tags are v0.9, named Sandy Boulevard Hooker, and v1.0, Cargo Freight Arterial, both from February 2014, which is a naming scheme that turns out to be street names for each release. Those tags have not moved in more than a decade, so the version history in the repository is not the version history of the running application, and the package version of 1.3.0 in package.json is the one to watch.

The fifth is the licensing. GitHub cannot classify the repository licence, but the package.json declares AGPL-3.0-or-later, and the copyright lines go to Code for America and contributors for 2013 to 2018 and to Streetmix LLC from 2019 to 2026. A copyleft licence on the client and server code means a city that wants to modify Streetmix and run a modified version has obligations, and a fork of a civic tool has to be thought about.

## Licence, maintenance and the cost of running a civic tool

The project is maintained by Bad Idea Factory with the support of many contributors, which is the arrangement a small civic product with an active community tends to have. The repository is not archived and the last push was on 2026-10-20, so the code is being worked on daily even though the release tags are ancient.

The public site is streetmix.net, and there is a Discord community linked from the README. The contributor guidelines live at docs.streetmix.net, and the local setup instructions are in the same documentation set under the local setup page, which the README points to for anyone who wants to run their own instance.

The funding model is worth noting because it says what kind of project this is. There is an OpenCollective sponsorship page, and the .env.example includes Patreon and Web Monetization configuration alongside the sponsor banner flag. A tool that is free to use and depends on a sponsoring community is a different proposition from a commercial product, and the configuration in that file shows the intent clearly.

The cost of running your own instance is a Node server, a Postgres database and a set of third-party accounts. The cost of running the hosted one is nothing but the design decisions it makes for you, since a hosted streetmix.net carries the geocoding, the map tiles, the image hosting and the account system, and those are the services a private deployment has to supply or switch off.

The other cost is the one the project is trying to reduce. Every engagement meeting a planner runs costs staff time and reaches a limited audience, and the argument for Streetmix is that a shared link keeps working after the meeting ends, that anyone can remix a design that was discussed publicly, and that the conversation happens in the tool instead of in a room that only some people could attend.

## Conclusion

Streetmix suits a planning team or a civic group that wants a low-friction way to collect street design input from people who do not draw, since the cut-and-assemble model needs no design skill. It does not suit a group that needs engineering-grade output, because a section is a communication drawing rather than a construction document. Read the local setup documentation and the .env.example before running it yourself, since the configuration surface is wide and partly optional.

## FAQ

### What is Streetmix and who is it for?

It is a collaborative process for communities and city planners to improve public spaces, where you design, remix and share a street cross-section. The goal is to promote two-way communication between planners and the public, and to reach a wider audience than community meetings allow.

### How do I set up my own Streetmix instance?

It is a Node.js based project. Copy the .env.example file to .env, fill in the required Auth0 values and the server configuration, then follow the local setup instructions in the project documentation. The repository ships a package.json with scripts for the development server, the client and the TypeScript watch build.

### What tests does Streetmix have?

Unit tests run under Vitest, with a server project variant and a coverage mode used in CI, JavaScript and CSS linting run through eslint and stylelint, and end-to-end tests run through Cypress. The top level test script runs the linters and the unit tests together.

### How do Streetmix street sections differ from engineering drawings?

A section is a cross-section view showing lane, sidewalk, tree and furniture widths and placement, and it can include engineering information such as slope for drainage and utility locations. But urban designers also produce simplified illustrative versions with most of the engineering particulars removed to show how a street could feel safe or walkable, and that is the register Streetmix works in.

## Sources

- [Issues](https://github.com/streetmix/streetmix/issues)
- [Project website](https://streetmix.net)
- [README](https://github.com/streetmix/streetmix/blob/main/README.md)
- [Releases](https://github.com/streetmix/streetmix/releases)
- [streetmix/streetmix on GitHub](https://github.com/streetmix/streetmix)

---

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