Bring an app from another tool

You can bring apps built with Lovable, Bolt, v0, or local development tools to Keelson if you have their source code. Compatibility and the changes needed for deployment depend on the app’s language, structure, and data storage.

Start by asking an AI agent to review the code, then review the required changes before deploying. Deploying the code does not move data or user accounts from external services to Keelson.

1. Get the source code

Export the code from the tool you used to build the app, or clone its Git repository locally. Open the app’s folder in your AI agent.

If you have not installed the Keelson CLI and Agent Skill or signed in to Keelson, follow steps 1 and 3 of the quickstart. When installing the Skill per project, run the installation in the folder of the app you are bringing over, rather than the sample app folder.

2. Ask your agent to review the app

Use a request like this:

I want to deploy this app to Keelson. Start at https://keelson.dev/llms.txt and read the linked supported apps and constraints page and Keelson Deploy Spec. Then review the code and explain whether it can be deployed and what needs to change. Check the database, login, file storage, and recurring tasks. Explain any changes that affect existing data or users’ access before making them.

Your agent will mainly check these areas:

What to check	Why
Language and framework	To confirm support and determine how to build and start the app
Data storage	To decide whether to keep the external database or switch to Managed SQLite
Login and permissions	To ensure existing users can still access their own data
File storage	To check whether stored files would be lost on restart
Timers and background work	To decide whether each piece of work moves to scheduled jobs (runs at set times) or background tasks (continues after a request)

See Supported apps and constraints for languages and frameworks, and How apps run for execution behavior.

If the app uses an external database or storage service

You can keep using external services that the app can connect to after deployment. In that case, you do not need to move the data. For example, an app using an external database should set db.mode: none and supply connection details.

Pass server-side API keys and passwords through secrets. Configure service URLs and public keys used by the browser according to the service’s instructions. Do not embed secret values in code sent to the browser.

If the browser calls a service such as Supabase directly, that service’s access controls still apply. Protecting the app with Keelson login does not automatically replace permissions on external data.

Opening a Keelson app requires Keelson login. If you keep the original login, users will need to sign in to both.

Whether you can remove the original login depends on how the app uses it to identify users and control data access.

Role of the original login	What to do
Only restricts who can open the app	Consider replacing it with Keelson login and app permissions
Restricts which data each user can see	Keep the original authentication, or change authorization to use Keelson user information
Stores the original service’s user IDs in data	Decide how to map existing users to Keelson users

For example, if Supabase row-level security (RLS) uses auth.uid(), removing login alone breaks the ability to identify whose data is being accessed. Check how data access works before deleting the login screen.

If the app stores data in local files

Data written to local files while the app runs does not survive restarts or redeployments. Choose persistent storage based on what you need to keep.

What you need to keep	Keelson storage
Customer records, projects, requests, and other data to search and update	Managed SQLite
Internal configuration files or records of processed data	Files SDK
Images displayed in the app, PDFs, and attachments users open	Media SDK

If you change storage, ask your agent to explain how to move existing data as well as how to change the code.

4. Deploy

Before deploying, install the Keelson CLI and Agent Skill and sign in to Keelson. If needed, follow steps 1 and 3 of the quickstart.

After reviewing the changes, ask your agent:

Make the changes we reviewed, create keelson.yaml, and deploy this app to Keelson.

The agent creates a configuration for your app’s structure. The main options are below; you do not need to write the configuration yourself.

App structure	How it is deployed
Static site / SPA (prebuilt HTML, CSS, and JavaScript)	Serve built files through `assets`. This includes apps that call external APIs from the browser
Web app with server-side processing (Next.js, Express, FastAPI, and others)	Start the web server with `command`
Static frontend combined with an API server	Set `assets` and `command`, and use `assets.api` to specify the API path (hybrid structure)

See Configure keelson.yaml to understand the settings and Deploy your app for deployment steps.

Building static sites and hybrid apps

Build static sites locally before deploying. Keelson receives the contents of assets.dir and keelson.yaml; it does not run npm install or npm run build for a static site.

For a hybrid app, build the frontend locally and place the output in assets.dir before deploying. Keelson builds the server-side code, but serves the uploaded files as assets.

Set service URLs and public keys that are read at build time before building. Setting server environment variables after deployment does not update an already-built frontend. Ask your agent to handle those settings together with the build and deployment.

5. Check the deployed app

The app opens at its Keelson URL and the required actions work.
Existing data appears, and new or updated data is saved.
Images and attachments can be viewed or opened.
Users can follow the intended login flow, including any original authentication you kept.
Other members can use the app, and cannot see data they should not have access to.

What does not move with the code

Databases, authentication, file storage, and server-side functions provided by the original tool do not move when you deploy source code. Keep connections to services accessible from outside the tool. Otherwise, you will need to migrate data or rewrite the affected functionality.

The original tool’s editing interface does not move to Keelson either. After deployment, change the code with your local AI agent or other tools, then redeploy.

Keelson SDK — Features, supported languages, and installation
Supported apps and constraints
Configure keelson.yaml
Environment variables and secrets
Framework notes