Connect what your app needs
6 minute read · Projects & Git
An app may need a database, a mail receiver or an API. Connect those resources once, then let the project reuse them without copying passwords into each conversation.
- Set the right context
- Open a saved tool or connection
- Pin connections to a project
- Try it in the website demo
- Keep changes deliberate
- Connect a resource to the app that uses it
- Review environment changes
- Diagnose a resource mismatch
- Connections and environment controls
Set the right context
Open the project settings and check its folder, startup command, tests, build command and preview address. Choose the intended named environment: local, staging, production or another configured environment. A name helps you recognize a target; it does not grant permission to change it.
The environment editor manages the project’s environment-file values. Saved connections can supply the resources the app needs. Supported Vercel integration can discover projects and pull environment values through an authorized saved provider connection.
Open a saved tool or connection
Use the saved tools and connections launcher to find a resource you already configured. Check its name and target before opening it, especially when local and remote environments have similar names. Reuse the saved SQL, SSH, FTP or API connection rather than creating a duplicate just to reach it from chat.
Keep supported tools docked in the workspace or floating inside Vortex. Position the tool beside the conversation or editor to compare a result with the code that produced it. Changing a panel's position does not change the connection's credentials, target environment or permission scope.
Project settings belong to a project. A plain chat has no project settings; attach or open the project before changing its environment, instructions or selected skills.
Pin connections to a project
Open Tools in the toolbar above a project chat. With an empty search field, Pinned connections shows that project's saved shortcuts in their configured order. Type in the same field to search the wider resource list. Pinning does not open a connection or start a process.
You can select saved resources in Project settings → Connections, or ask the agent: “Pin this project's development database and API in Pinned Connections.” The agent can discover existing SQL databases, SSH hosts, FTP/SFTP connections, API collections and local or cloud Signals apps, then save the selected references directly to the project. No separate external MCP setup is needed for this built-in conversation workflow.
| Action | Result |
|---|---|
| Pin a saved connection | Adds a project shortcut. Pinning the same connection in the same environment again does not add a duplicate. |
| Rename a pin | Changes its project label, leaving the saved connection's name and credentials intact. |
| Reorder pins | Changes their order in Pinned connections. |
| Assign an environment | Associates the pin with Local or an existing project environment. It does not change the server or rewrite .env. |
| Unpin | Removes the project shortcut. The saved connection and its server data remain available. |
| Open a pin | Opens that resource over the project; the chat and its draft stay in place. |
For example, ask “Put the API first and label the local database Sunday development.” Then reopen Tools and check the order and labels. When one SQL profile contains several databases, choose the intended database, not just the server name. Local and cloud Signals apps remain separate even when their names match.
The agent uses the selected included project and the conversation's access mode. Plan mode can inspect pins; making a change requires Build. If the Vault is locked or a resource module is unavailable, resolve that condition before retrying. A missing or failed connection listing must not produce an invented pin. Read the saved result back after a change; if someone changed the pins while an approval was pending, refresh the list before retrying.
Try it in the website demo
In the interactive demo, send Pin project connections. A prepared reply adds the example Sunday database and API to Tools → Pinned connections. Open either to explore its sample data. Send Unpin project connections to remove those shortcuts; the example resources remain searchable. Reset restores the initial demo. The demo makes no AI request and does not connect to a real server.
Keep changes deliberate
Begin with local resources while building the first version. Before a database write, remote command or deployment, confirm which environment and saved connection will be used. Ask the agent to explain the proposed action when the destination is unclear.
If the app cannot connect, compare the selected resource, host/port and running service. Read the specific error without publishing the credential. Fix the intended configuration instead of creating duplicate connections until one works.
Learn to open the database, capture a test email or check before publishing.
Connect a resource to the app that uses it
Suppose Small Stories uses a local database and sends a welcome email. Save the local database connection in Database and create or select a development SMTP resource. Associate the appropriate resources with the project environment, then configure the app's environment file through the project editor or an authorized agent action. A saved Vortex connection and the app's own environment file are related configuration, not the same storage location.
Use recognizable names such as Small Stories local and Small Stories staging. Before asking an agent to inspect data, name both the project and environment. Never assume that switching the visible environment automatically copies data, applies migrations or makes production safe to modify.
Review environment changes
- Confirm the intended environment and the file or saved resource being changed.
- Enter private values through the credential/environment UI, not an ordinary conversation.
- Save and inspect any error. Preserve a working configuration before replacing several values at once.
- Restart only the project process that needs the new settings, if its framework requires it.
- Verify the connection through a small request, query or captured development message.
Vercel integration can discover projects and pull environment values through a saved provider connection. Forge or command-based deployment configuration belongs to a specific target. Selecting such a connection does not authorize publishing; ask for the exact operation separately.
Diagnose a resource mismatch
If the app reads different rows from Database, compare the configured host, database/schema and environment without printing the password. If mail does not arrive in the catcher, check which SMTP settings the app process actually loaded. A stale process can retain older environment values. Use Database and test mail to verify those paths directly.
Connections and environment controls
Project settings → Connections selects which saved resources belong to the project. Use the existing database, API cluster, SSH host, FTP connection or Signals app by its recognizable name. Selecting a resource supplies project context; it does not copy its password into the project instructions.
Tools opens saved tools and connections. Choosing an entry opens the existing resource, while its available dock/float controls change its view. Close and expand/restore affect the panel. Editing or deleting the saved connection uses its separate resource-management action.
Project settings → Environments manages supported .env files. Select the intended file, inspect names/values and save through the editor. A process may need a restart to read changed environment values. Linking a saved database connection does not automatically rewrite an application's .env; verify the actual configured host/database afterward. See project runtime.