> ## Documentation Index
> Fetch the complete documentation index at: https://archie.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Editing the tech stack

> Choose and adjust the technical foundation for your app.

The tech stack section of the blueprint sets the technical foundation Archie generates against — frameworks, runtime, database, hosting model. This page covers when and how to change it.

## What is in the tech stack

The tech stack card lists Archie's choices for:

* **Frontend framework**
* **Backend framework / runtime**
* **Database**
* **Authentication library**
* **Other infrastructure components** (caching, queueing, and so on, when relevant)

<img src="https://mintcdn.com/archie-e998dbf6/eiHdGPkQDkoCG39-/features/blueprint/tech-stack-list.png?fit=max&auto=format&n=eiHdGPkQDkoCG39-&q=85&s=d4af4cebddcdf2b9844e4281148c6340" alt="Tech stack card with frontend, backend, database, and auth choices" width="1680" height="384" data-path="features/blueprint/tech-stack-list.png" />

## When to change the tech stack

Most users should leave this section alone on the first build. Archie's defaults are sensible for the kind of app you described. Reasons to override:

* You have an existing infrastructure standard (Postgres, not the default DB)
* You are handing off to a team with specific framework expertise
* You need a specific runtime for a downstream constraint (edge, on-prem)
* Your idea implies an unusual stack (a CLI, a desktop app)

If none of these apply, leave the defaults.

## Changing a stack choice

Open the tech stack card. Each component has a dropdown or text field. Pick the new choice. Save. The generator will use the updated stack on the next build.

## When to regenerate vs. edit

* **Direct edit** is fine for swapping one component for another (for example, MySQL → Postgres).
* **Regenerate** the section if everything looks off — for example, a desktop-app stack when you wanted a web app.

## Tradeoffs to be aware of

* Swapping frameworks **after** a build is expensive — most code is framework-specific. Change the stack at the blueprint stage if you can.
* Some integrations work better with specific stacks. {/* VERIFY: confirm whether Archie warns when an integration and stack are mismatched */}
* The tech stack you pick affects the credit cost of generation. {/* VERIFY: confirm credit variance by stack */}

## FAQ

<AccordionGroup>
  <Accordion title="What happens to my code if I change the stack after building?">
    The next build regenerates against the new stack. Custom edits made to the previous code will not carry over automatically.
  </Accordion>

  <Accordion title="Does the stack affect deployment options?">
    Yes. Some stacks are easier to deploy to specific targets. See <a href="/features/frontend/deployment">deployment</a>.
  </Accordion>
</AccordionGroup>