SERVICEBackend Setup

Backend Setup for Purchased App Templates

You bought an app template that comes with a backend: a Laravel admin panel, a Node API, or a Firebase project the app expects to find. The app builds, but it still talks to the author's demo server, or to nothing at all. We deploy and configure the backend your template already ships with, on accounts in your name, and point the app at it. It's included in our $150+ Pro reskin, or quoted at a fixed price on its own.

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.json and GoogleService-Info.plist, or firebase_options.dart generated 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.

Pro bundle or standalone

Backend setup is part of our Flutter app reskinning service at the Pro tier. If you also need your brand, package name and signing done, that's the cheaper way to buy it, because the Firebase registration depends on the final package name anyway and it makes sense to do both in one pass.

Pro reskinBackend setup only
PriceFrom $150, fixed quote after we see the templateFixed quote after we see the template
Backend and Firebase setupIncludedIncluded
Brand, package name, signingIncludedNot included
Store-ready release buildIncludedRelease build tested against your server
Revisions and support2 revisions, 30-day supportStated in your quote
Turnaround5–10 business daysStated in your quote

Why no standalone number? Because the spread is real. A Firebase project for an app with push and Google sign-in is a different job from a Laravel admin panel that needs a VPS built from scratch, a database import and five third-party keys. We'd rather see the template and give you one fixed figure than publish a “from” price that doesn't fit yours. The quote comes before any work starts.

Our turnaround starts once we have everything in the list below. Account verification on your side, such as a new Apple Developer enrolment or a hosting provider's identity check, can take longer than the setup itself, so start those first.

What we need from you

  1. The source code for the app and the backend, exactly as downloaded. If you already started installing, tell us how far you got and what failed.
  2. The author's installation documentation. Every template's server requirements differ, and we follow the author's documented setup rather than guessing.
  3. Your licence or purchase receipt. Some installers also ask for the marketplace purchase code.
  4. Hosting or VPS access and a domain, or a note that you don't have them yet. We'll tell you what the template needs before you pay for anything.
  5. DNS access for the domain, or someone who can add records when we ask.
  6. A Google account to own the Firebase project, if the template uses Firebase. Where a provider lets you add a team member, we ask for that instead of your password.
  7. Your final package name and bundle ID. Firebase locks them per registered app, so choose before we start.
  8. Apple Developer account access if you need iOS push notifications, for the APNs key.
  9. Play Console access if the app is already uploaded, so we can read the app signing key fingerprint.
  10. Accounts for any third-party service the template uses: maps, payments, ads, email.

Missing some of this? Send the brief anyway and we'll tell you what to set up first.

FAQ

Frequently Asked Questions

The questions buyers ask before they send us a template with a backend.

Yes. Envato's item support policy says support doesn't include installing the item on your server or problems in your hosting environment. It covers questions about the item's features. Some authors sell installation as a separate paid service, and if theirs fits your template and budget, it's a reasonable choice. We're the option for buyers who want the backend, Firebase, branding and signing done by one team in one pass.

Not as part of this service. Backend setup means deploying what your template already ships with. Adding sync, user accounts or a web dashboard to an offline app means new data models, a server and moving existing data, and that's custom development, quoted separately. Our own Flutter templates fall in this group: they're offline-first with no server, so there's nothing to set up unless you decide to add one.

That's a rebuild of the backend, not a setup, so it's outside this service and the Pro reskin. Tell us what you want and why, and we'll quote it as custom work. Often the cheaper path is to deploy the backend the template was built for and get to launch first.

You do, directly to your hosting provider, every month the app is live. We can't give you a figure. It depends on the provider, what the template needs to run, your user count and your data volume. Before you buy anything, we tell you what your specific template requires, so you're not paying for a bigger server than it needs. Firebase has its own pricing; check its current pricing page for the products your template uses.

Usually a missing fingerprint. With Play App Signing, Google signs the app users download with its own app signing key, and Google's help page says you must register that key's fingerprint with API providers, not only your upload key's. If Firebase only knows your debug or upload SHA-1, the store build doesn't match. Copy the SHA-1 and SHA-256 from the app signing key section of your Play Console's app signing page into your Firebase app settings. We add all three keys during setup.

Firebase's current documentation authorises server-sent push messages with a service account key and short-lived OAuth 2.0 tokens, not a single server key string, and the older server-key method is deprecated. Some older admin panels still show the old field. If the panel already supports the newer method, we configure it. If its code only supports the old one, updating it is code work: we'll tell you after seeing the template, and it goes into the fixed quote.

As few as possible. Where a provider supports adding a team member, we ask for that instead, and you remove us when the work is done. Everything we create, from the database to the Firebase project to the admin account, is created in your name and handed to you. We don't host your backend on our accounts. All projects are under NDA by default.

As part of a Pro reskin, our part is typically 5–10 business days once we have everything in the list above. For backend setup on its own, the timeline is in your quote, because it depends on the template. Most delays come from waiting on account access or a provider's verification, not from the setup itself. Store review comes after that and isn't something we control.
Ready to Deploy

Ready to get your backend live?

Send us the template name, where you bought it, and what's already set up. You'll get a fixed-price quote back before any work starts.