Is this for you?
It is if your template's documentation has an installation section that starts with a server. You uploaded the admin panel, the installer threw an error, and the author's support reply said installation isn't covered. That's not the author being difficult (Envato's item support policy says support doesn't include installing the item on your server or problems in your hosting environment). Some authors sell installation as a paid extra; many don't.
It's also for you if the template uses Firebase and you're not sure which project, which package name, or which config file. Or if push notifications, Google sign-in or maps worked in the author's demo and stopped working in your copy.
It isn't for you if your app has no backend and you want one added: sync between devices, user accounts, a web dashboard that doesn't exist yet. That's new development, not setup, and we quote it separately as custom work. The same goes for replacing the backend your template ships with by a different technology, such as moving a PHP admin panel to Firebase.
If you bought one of our own Flutter templates, you probably don't need this at all. They're offline-first: data lives on the device and there's no server to deploy. Our help article on whether your Flutter template needs a backend explains what that means and when it changes.
What's included
Everything below is configured on accounts you own. Where a step depends on what the template ships with, we do the version your template uses and skip the rest.
Server, domain and database
- Hosting or VPS set up for the template. We install what the author's documentation requires on a hosting account or VPS in your name. If you don't have one yet, we tell you what the template needs before you buy.
- Domain pointed at the server. DNS records for the domain or subdomain the API and admin panel will live on.
- SSL certificate, so the app connects over HTTPS. This isn't optional polish. Android 9 and later block plain HTTP by default, and Apple's App Transport Security blocks connections that don't meet its TLS requirements. An app pointed at an
http://address often works on the emulator and fails on a real phone. - Database created and the template's schema or SQL file imported, with the author's demo records removed.
- Admin panel installed and configured: app name, your logo where the panel shows one, mail settings if it sends email, and the first admin account handed to you.
Firebase setup service for Flutter apps
If the template uses Firebase, a package name change means a new Firebase registration. Firebase doesn't let you change the package name or bundle ID on an app once it's registered, so we register yours, once, after the name is final.
- Firebase project created in your Google account, with you as owner.
- Android and iOS apps registered under your package name and bundle ID, and the config wired into the project:
google-services.jsonandGoogleService-Info.plist, orfirebase_options.dartgenerated with the FlutterFire CLI, depending on how the template was built. - SHA certificate fingerprints added for every key that signs your app: your debug key, your upload key, and, once the app is in Play Console, the Google-held app signing key. With Play App Signing, the copy users download is signed by Google's key, not yours. Register only your own key and Google sign-in can work in testing and break in the store build.
- Push notifications (FCM). On iOS that needs an APNs authentication key from your Apple Developer account, uploaded to Firebase. Where the admin panel sends pushes, we configure its server-side credentials with a Firebase service account key and keep that file off the app and out of public code.
Third-party keys and the app itself
- Third-party keys swapped for yours: maps, payment provider, social sign-in, ad unit IDs, whatever the template uses. Firebase's own API keys aren't secrets, but other keys should be restricted to your app, and we set the restrictions the provider supports.
- The app pointed at your server. The API base URL and any hard-coded author endpoints changed to yours.
- Release-build checks. Flutter's standard Android template doesn't include the internet permission for release builds, so an app can work in debug and go silent once released. We check for it, then test a release build against your live server: login, the main data screens, a push notification.
Handover
- A written list of what runs where: server, domain, database, Firebase project, which keys are used and where each one lives in the code.
- Every credential we created, handed to you. We don't keep accounts in our name.
- Full source code with all changes.
- 30 days of support for problems with the work we did, as part of the Pro package.
What's not included
- Adding a backend, sync or accounts to an app that doesn't have them.
- Swapping the template's backend for a different technology.
- New API endpoints or admin features the template doesn't already have.
- Hosting fees. You pay your provider directly, every month the app is live. Our quote covers configuring the server once, not running it.
- Ongoing server maintenance after the support period.
- Uploading to the stores and handling review. Pro ends at a store-ready build.
Before launch, also check your store privacy forms. Google Play counts data your app sends to your own server as collected, so the Data safety form and Apple's privacy label need to match what your backend actually receives. We can tell you what the template sends; the declarations are yours to make.