Build
Applications
Learn which web, server and mobile applications Amazi supports, their preview and build limits, and application settings.
Independent applications
One Amazi project can contain several applications, such as a website, a server that stores its data, and a mobile app. Each has its own files and settings. You can view, run, or publish it according to the capabilities described below.
Describe what you want to create, who will use it, and where it should work: in a browser, on a phone, or on a computer. Amazi prepares the required application settings. Being able to write its code does not always mean Amazi can show or run the result inside the editor.
A starter supplies an initial set of files and settings. The agent adapts it to your request. You can also provide existing application source code to continue working on it.
Supported application types
Creating source code, showing a preview and producing a deployable application are separate capabilities. Current support depends on the application type:
| Application type | What you can do in Amazi | Limits and external steps |
|---|---|---|
| Websites and web apps with React/Vite or Next.js | Create and edit code, run the app, use browser Preview and publish it | No external build is required for the supported web workflow |
| APIs and server apps with Node/Express or Python/FastAPI | Create and edit code, run and deploy the server, expose a public HTTP address when enabled | An API is not a visual interface in Preview |
| Mobile apps using React Native/Expo | Create and edit the app, view its web version in Preview, and request an Android build | Preview does not run the Android or iOS app; test the result on a device. iOS builds and store submission happen outside Amazi |
| Mobile apps that open a website inside the app (WebView) | Use a new or existing website and request an Android build | The wrapper has no Preview in Amazi. Test it on a device; iOS builds and store submission happen outside Amazi |
| Electron desktop apps | Create and edit a React/Vite desktop application with prepared components | Desktop execution, installers, signing, and device verification require an external computer or build service |
| Other Android apps using Java/Kotlin | Write and edit code; build compatible projects | Ask the agent to check build support for your project. Amazi does not show the running Android app; test it on a device |
| Apps using Swift, Flutter/Dart, or other tools unavailable in Amazi | Get help writing and editing code | Building, running, and testing require a suitable computer or build service; these apps have no Preview in Amazi |
Other web and server frameworks may work when their dependencies and startup requirements fit Amazi's available runtime tools. Ask the agent to check compatibility before relying on preview or publication.
Stack defaults
For a new web frontend, Amazi uses React/Vite without asking you to choose a framework. A needed backend defaults to Node/Express/Prisma. Describe your product rather than selecting technologies unless you have a requirement. If you explicitly request a different stack, Amazi explains the default and the alternative and asks for confirmation. Existing source preserves its technology.
Web, Electron, and Expo starters include reusable table components and form examples with required markers beside labels. These are starting components, not completed business features.
Mobile applications
Amazi offers two starting points:
- An app that opens your website (WebView). This is the default for a mobile app request. You can use an existing website or create one with Amazi. The website can be viewed separately, but the mobile wrapper itself has no Preview in the editor.
- An app using React Native/Expo. Ask for this option if you need it; Amazi will explain the differences and confirm your choice. Preview displays its web version in a browser. It does not run Android or iOS, and features that need a phone must be tested on a device.
For an Android build, ask: “Build an APK so I can install and test the app on my phone.” Amazi can prepare the build tools and produce the file for a compatible project. An APK is a file for installing an Android app. An AAB is a package for submission to an app store; it is not installed directly like an APK. You can request the required format in chat.
Open and test the built app on a phone or in an emulator outside Amazi. A successful build or a working web preview does not confirm that every feature works on the phone. Amazi does not provide an Android or iOS emulator in the editor.
Before distribution, choose the app name and icon and prepare release signing. Keep the existing signing key for updates to an already released Android app. A build made for testing is not automatically ready for a store. Store submission is a separate step outside Amazi.
For iPhone and iPad, Amazi can help with the code, but building the app requires a Mac with Xcode or a separate build service. Publishing a website in Amazi does not build an iOS app or submit it to the App Store.
A mobile-friendly website alone does not select either mobile option. If you provide existing application source, Amazi starts from an empty application and preserves that source's technology.
Capabilities and editor adapters
Request tracking has separate optional adapters for Node.js, Python, Vite and Next.js. They do not enable element selection or change how your application runs. If an application card in Application connections shows a warning, open it to prepare a setup request for the agent. See Preview, Code, and application connections for coverage and publication requirements.
An application with Preview enabled can appear in the editor iframe. Public URL independently controls whether Amazi exposes its HTTP route, so an API can have a public address without appearing as a visual preview.
Amazi includes web and server applications in publication. Mobile, desktop and other application types stay in the catalog with any available preview, but their publishing status is gray and they are skipped by Publish all and Update all. To get an Android app, request its build separately; those buttons do not create an installation file or submit an app to a store. You can also ask Amazi to disable publication for a specific web or server application.
New applications created from the Next.js starter hide its development badge in Preview by default. Existing applications retain their own settings.
Editor adapters are optional enhancements. Next.js App Router navigation discovers Preview routes from src/app or app. Next.js JSX source selection and Vite JSX source selection link rendered elements to JSX or TSX source through framework-specific development integrations. TanStack Router navigation reports routes and supports editor navigation. Preview still works without these adapters, and an adapter failure must not stop the application.
Environment and managed PostgreSQL
Applications with Common environment access receive only common project variables. Applications with Server access receive common and server variables plus eligible runtime-owned server credentials. Common variables must never contain secrets.
A project can have one managed PostgreSQL database and many server-access applications. Exactly one application can be assigned as its owner and receive DATABASE_URL. Development and production use the same URL, schema, and rows; a development write is therefore a production-data write. Stopping either environment or removing the owner preserves the project-level database, and another server-access application can be assigned later.
Temporary files
Inactive projects keep their files and installed dependencies. Automatic stopping does not remove Git-ignored files. The workspace-root .gitignore controls which files Git tracks. An application's .dockerignore remains separate and affects only Docker builds.