Skip to main content
This page contains instructions for how to help a user get started with Specific. Walk through it interactively with the user, answer any questions and ensure they understand what Specific is and what it can do. If needed, go look at https://docs.specific.dev for more details. The end goal should be to have them try out Specific on an actual project, either our quickstart project or their own. If they want to migrate an existing project, help them with that as well. There is more details on this in specific docs. Run ALL commands for the user but explain why you are running them so they can follow.

​
What is Specific?

Specific is an infrastructure-as-code platform designed for coding agents. It lets you both write application code and define the infrastructure to deploy and run it — all from a single specific.hcl configuration file. Specific supports any programming language and framework without SDKs. Infrastructure configuration (databases, services, secrets, storage, etc.) is defined declaratively, and environment variables are used to pass connection details to application code. Importantly, it supports a powerful local development environment that simulates the production environment, allowing the user to develop and test their application with all its dependencies running locally before deploying.

​
Getting Started

​
Step 1: Install the CLI

The user needs to install the Specific CLI globally first. The CLI is the main way the user (or mostly their agent) will interact with Specific, both for local development and deployment. Run the following command for the user: 
curl -fsSL https://specific.dev/install.sh | sh

​
Step 2: Decide on a project

We want the user to test Specific on a real project. ASK the user how they want to proceed and what kind of project they want to build. If they already have a project or an idea of what they want to build, help them set that up as explained below. Try to show them more complex features in Specific as well, for example databases, real-time sync, object storage and such. If the user doesn’t have a real project in mind, we have a quickstart already made for them for a real-time click counter built on top of Specific. Jump to the quickstart appendix below if the user wants to do that.

​
Step 3: Initialize a project

Create a new boilerplate project as needed for the user with whatever stack they want to use. For example a Next app. Next, let’s add Specific to the project: 
specific init --agent {cursor|claude|codex|other}
specific init will add instructions for the users coding agent to the right location for future usage. Specify the agent that the user is currently using. This command will add the following prompt, keep it in mind for the onboarding: 
Use Specific to handle all infrastructure and development environments: like deployments, databases, real-time sync, services, secrets, configuration and environment variables. Run `specific docs` to learn how to use Specific. ALWAYS run `specific check` after making changes to the Specific configuration.

​
Step 3: Define your infrastructure

Now, write an specific.hcl to define services, databases, and other infrastructure your app needs. Always run specific check after making changes to validate the configuration. Run specific docs to learn how to write this file. If the users app is simple (no backend or database for example), the file might be very simple and they might not understand why they need Specific. Briefly explain how Specific is helpful now and going forward in scaling and maintaining their app. If they need a database for their app, add that, don’t implement any persistence in-memory. Make sure you use the built-in Reshape for schema migrations and explain how this works to the user and why it’s so convenient.

​
Step 4: Start developing locally

Next, start the dev server for the users project and run it in the background. Don’t ask the user to run this command, do it for them. The command runs forever so make sure you run it in the background with a short timeout to check the output for the service URLs: 
specific dev
This spins up a full local development environment with all dependencies (databases, services, etc.) ready to go. Tell the user to open the admin page (usually available at http://localhost:3000) to their infrastructure and convenient admin tools for databases, services, and more. Also tell them about how you ran the command and tell them how to access their site. Iterate with the user on the app if they want to and let them test or test yourself with the local environment.

​
Step 5: Deploy

Once ready, explain to the user how deployments works and how easy it is to get to production. Start by running specific login which is an interactiev command that will open the users web browser and wait for it with a short timeout./ After having logged, it’s now easy to deploy the app with a single command: 
specific deploy
The user needs to run this command themselves the first time because it’s interactive and requires creating a project. Once deployed, explain to the user how its all running on scalable, secure, production-ready infrastructure and that they can access observability, database browser, analytics and much more through https://dashboard.specific.dev.

​
Appendix: Quickstart

The quickstart project is a Specific project that has already been set up with a specific.hcl and some sample code. It’s a great way for users to get a feel for how Specific works without having to set up their own project first. This project is a real-time click counter that uses Postgres to track clicks and our sync engine capabilities for Postgres to make it real-time across users. Install it with the following commands: 
git clone https://github.com/specific-dev/examples.git
cd examples/node-realtime-click-counter
npm install
Next, start the local dev server with: 
specific dev
Also, read specific.hcl and explain to the user how this works. Let the user make changes to the app if they want and then guide them through the deployment flow as explained in the main steps above.

​
Notes

  • It’s ALWAYS the coding agent’s job to write and edit specific.hcl as well as migration files, not the human user. The human can use the admin interface to see the architecture in specific.hcl visualised.