Skip to main content
A Devin App is a web app that Devin builds for you and keeps serving from its own machine. It can be an internal tool, a dashboard, a form, a tracker or a demo. Each App has a stable URL that you can share with your team. Apps are served the same way as browser previews. A preview is for looking at work in progress in one session, and it is enough for most work. An App is for something your team keeps using after the session’s work is done.
Devin Apps are rolling out gradually. If you don’t see Apps in your sidebar, they are not turned on for you yet.

​
How Devin Apps work

  • The App runs on Devin’s machine. Devin builds the App in a session and serves it from that session’s machine. Nothing is deployed to a third-party host.
  • Any stack works. Devin can use whatever framework and language fit the job, as long as the result serves HTTP on a port.
  • Your data stays on the machine. The App can use any database you like, such as SQLite or Postgres, running on the same machine. Files and uploads live there too.
  • The URL is stable. An App’s URL looks like https://<name>--<id>.preview.devinapps.com. It stays the same across every update, and renaming the App does not change it. Devin knows the URL and gives it to you when the App is live.
  • Apps are private. Everyone who opens an App has to sign in to Devin. You choose who has access. Apps are never public.
  • A session manages the App. The session that builds the App also ships later changes. To change an App, message its session.

​
Use cases

  • Beta and staging versions of your product. Devin can run your company’s real stack on its machine: your frontend, your backend, your database and any workers. That makes a Devin App a good home for a beta or staging copy of your app that teammates can open from a link, without setting up separate hosting.
  • Internal tools. Admin panels, request forms, approval queues, and small tools that replace a shared spreadsheet.
  • Dashboards. Metrics, on-call health, support queues or sales numbers, pulled from your own data sources and refreshed on a schedule.
  • Rollout trackers. A page that shows where a migration, launch or feature flag rollout stands, and what is left.
  • Demos and prototypes. A working version of an idea that people can click through before you build the real thing.

​
Creating an App

  1. Open Apps in the sidebar.
  2. Describe what the App should do. You can also pick a prompt template to start from.
  3. Send the prompt.
You land in a new Devin session. Devin asks any questions it has in its first message, then builds the App and puts it online. The App shows up under Apps right away with its URL, and its status is Building until the first version is live. You can also ask for an App in any session, for example “build this as a Devin App”. If Devin has already shown you a browser preview, you can ask it to publish that preview as an App.

​
Sleeping, waking and billing

Devin’s machine goes to sleep when nobody is using it. When someone opens the App, the machine wakes up and serves the page. The first load after a sleep can take a few seconds. The machine goes back to sleep 5 minutes after the last request. Billing for an App is based on how long the machine is awake. An App that nobody visits does not use anything while the machine sleeps. Building and changing the App is normal session work and is billed like any other session. See Usage.

​
Sharing an App

Click Share on an App to copy its link or change who can open it. General access has three levels: You can also add specific people, groups or organizations and choose what each can do: open the App, edit its settings, or share it with others. Organization admins can set the default sharing level for all of the organization’s Apps under Sharing defaults.

​
Finding and pinning Apps

The Apps page lists the Apps you can open, with search, categories and filters. You can pin the ones you use most. There are two kinds of pin:
  • Pin for me keeps an App at the top of your own Apps home.
  • Pin for everyone puts an App at the top of the Apps home for the whole organization. Only organization admins can do this.
If you like someone else’s App, Use as a starting point starts a new App based on it.

​
Updating an App

Open the App and click Edit in session, then tell Devin what to change. Devin makes the change, builds a new version and puts it online. The URL does not change. Every update is a new version. The App’s page lists them under Deployments, with the status, a description, and the commit for each one. If a new version fails to start, the previous version keeps serving. To go back to an older version, ask the session to deploy that version again. The App’s page also shows page views for the last 24 hours, 7 days or 30 days. The App’s creator and organization admins can open its settings to rename it, edit the description, set a cover photo, take it offline or delete it. Taking an App offline keeps its history. Deleting it makes the URL stop working. Neither one affects the session.

​
How Devin builds Apps

Devin follows a set of built-in instructions when it builds an App. These are the parts worth knowing about:
  • It serves a production build. Devin develops against a dev server and checks its work in a browser preview. When the App works, it builds it and serves the production build, not the dev server.
  • It keeps the code in git. Devin commits before every deploy, so each version matches a commit. If the App lives in one of your repositories, Devin pushes the commits or opens a pull request.
  • It keeps data out of the build folder. Database files and uploads are stored outside the folder that gets rebuilt, so an update or rollback does not wipe them.
  • It uses your brand. Unless you ask for a specific look, Devin looks for your company’s design system in your repositories and uses its colors, fonts and components. It tells you where the brand came from. If it can’t find one, it uses a plain default style.
  • It asks questions up front. People often leave after sending a request, so Devin asks everything it needs in its first reply.
  • It does not leave a broken version. If a deploy fails, Devin reads the error, fixes it and deploys again.
  • It makes a thumbnail. After a deploy, Devin takes a screenshot of the App for its card on the Apps page.
You can override any of this in your prompt. For example, you can name the stack, the database or the look you want.

​
Keeping an App up to date with automations

An App does not have to wait for you to ask for changes. An automation can wake Devin up and have it update the App for you. Two common setups:
  • On a schedule. Devin wakes up every hour, every day or every week, pulls fresh data, and updates the App. This works well for dashboards and reports.
  • On every push. If the App follows a branch in one of your repositories, Devin redeploys it each time the branch changes.
Ask the App’s session to set this up. Devin creates the automation and you approve it once. You can also create it yourself on the Automations page and have it message the App’s session.
Every automation run is a Devin session, and it is billed like one. An App that updates every few minutes can cost much more than the App itself. To keep the cost down:
  • Run the automation less often. Most dashboards do not need to be fresher than hourly or daily.
  • Pick a more cost-efficient model for the automation’s sessions.
  • Keep the work small. Ask Devin to write a script that fetches only the new data and to run that script on each update, so it does not work the problem out again every time.
  • Set an ACU limit on the automation. See Limits and safeguards.

​
Secrets and other services

An App can read data from other services and write to them. Devin sets this up the same way it does in any session.
  • API keys for other services. Add the key as a secret and tell Devin which service it is for. Devin gives the key to the App’s server, and the App calls the service from there. Keep keys on the server side of the App. Anything sent to the browser is visible to everyone who can open the App.
  • The Devin API. An App can call the Devin API with a personal access token or a service user key. This lets you build your own tools on top of Devin, such as a page that starts sessions from a form, or a dashboard of your team’s sessions. A personal access token acts as you, so everyone who uses the App acts with your permissions. Share an App like this with care.
  • Sign-in. Everyone who opens an App has already signed in to Devin, so most Apps do not need their own login.
Secrets live on Devin’s machine with the rest of the App. They are not part of the App’s sharing settings, and people who can open the App can’t read them unless the App shows them.

​
When an App is offline

An App depends on its session. Keep these in mind:
  • Archiving or ending the session takes the App offline. Devin warns you before you archive a session that serves an App. Unarchive or resume the session to bring the App back.
  • Nothing restarts a crashed server. If the App’s server stops, the URL shows an error page until Devin starts it again. Open the App’s session and ask Devin to deploy it again.
  • An App with no live version shows an offline page. This is what you see before the first deploy finishes, or after someone takes the App offline.
In each case, the fix is to open the App’s session from the Apps page and ask Devin to deploy.

​
Limits

  • Apps can’t be made public. Visitors always sign in to Devin.
  • Apps can’t register their own service worker, so offline mode for PWAs is not available.
  • The App runs on one machine. It is a good fit for internal tools and dashboards, not for high-traffic production services. For those, deploy to your own infrastructure with your existing CI/CD and give Devin access through Secrets and Skills.