Foodifly documentation

📋Overview

Foodifly lets you run a food delivery marketplace. Customers order from restaurants, riders deliver, restaurants manage their menu and orders, and you run everything from one admin panel. All of the clients talk to the same Laravel backend (/api/v1) and receive live updates through Pusher and push notifications through Firebase.

Feature highlights

Built to work in any country

Nothing in the code is tied to one country. Currency, timezone, support contacts, delivery fees, minimum order, tip amounts, wallet limits and loyalty rules are all set in the admin panel (Settings) and picked up by every app and website automatically.

📦What's in the package

The download contains six applications. Each lives in its own folder inside main/:

⚙️Requirements

Server (backend and admin panel)

PHP extensions

For the web clients

• Node.js 22 LTS (or 20.19 and newer) to build and run the restaurant portal and the customer website (Next.js 16).
• Composer 2 and Node.js 22 LTS (or 20.19 and newer) with npm are needed once, to create vendor/ and public/build/ for the backend (step 0 of the install). Run them on the server over SSH, or on your own computer and upload the result.

Mobile app compatibility

Accounts you need (third-party services)

Foodifly depends on a few services run by other companies. You create and pay for your own accounts; nothing is shared with the author. Most have a free tier that is enough to start. See External services and outbound connections for exactly when each one is contacted.

To build the mobile apps

• Flutter 3.41.9 (the version the apps were built and tested with).
• Android Studio with the Android SDK, and for iOS a Mac with Xcode and an Apple Developer account.
• A Firebase project (push notifications), a Google Maps API key (Android and iOS), and a Pusher Channels app (live updates). See the configuration sections.

🚀Install the backend

You can install with the web installer (no command line needed) or from the command line. Both give the same result.

Step 0: Get the packages and build the admin styles (once)

In the backend folder, run these three commands:

cd backend-and-admin-panel
composer install --no-dev --optimize-autoloader
npm ci
npm run build

• They create vendor/ (PHP packages) and public/build/ (the admin panel's CSS and JS). After npm run build you can delete node_modules/.
• No SSH on your hosting? Run the commands on your own computer (Composer 2 and Node.js 22 LTS or 20.19+ installed), then upload the whole folder, including the new vendor/ and public/build/.
• The web installer's first step checks both folders and tells you the command if one is missing.

Option A: Web installer

1. Upload the files. Upload the contents of backend-and-admin-panel to your server and point the domain's document root at its public folder. Do step 0 first, so the folder you upload contains vendor/ and public/build/.
2. Create an empty MySQL database and a user with access to it.
3. Open https://your-domain.com/install/ and follow the steps (the last one is the finish page):

Option B: Command line

# 1. Upload the code, create the database, then (step 0 above):
composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate

# 2. Edit .env. At minimum:
#    APP_ENV=production   APP_DEBUG=false   APP_URL=https://your-domain.com
#    DB_*                 QUEUE_CONNECTION=database
#    ADMIN_EMAIL / ADMIN_PASSWORD   (quote the password if it has spaces or #)

# 3. Install, migrate, build caches (also runs npm ci && npm run build)
bash scripts/deploy.sh

# 4. Create roles, permissions, default settings and your Super Admin (once)
php artisan db:seed --class=ProductionSeeder --force

Without an ADMIN_PASSWORD, a random one is generated and printed once. Locked out or need another Super Admin later? Run php artisan foodifly:create-admin --email=you@example.com.

Then sign in at https://your-domain.com/login.

✅After installing

Work through this list once. The admin panel shows whether the queue worker and scheduler are running under Settings → Firebase & Push.

1. Start the queue worker. Push notifications, emails and payouts are queued; without a worker they are saved and never sent. With Supervisor:

   sudo cp deploy/foodifly-worker.conf /etc/supervisor/conf.d/
   sudo nano /etc/supervisor/conf.d/foodifly-worker.conf   # set your path and web-server user
   sudo supervisorctl reread && sudo supervisorctl update
   sudo supervisorctl status foodifly-worker:*              # should say RUNNING

2. Add the scheduler to cron (takes riders who closed the app offline after 30 minutes, and reports its heartbeat to the admin):

   sudo crontab -u www-data -e
   # add the line from deploy/foodifly.cron, with your path:
   * * * * * cd /var/www/foodifly && php artisan schedule:run >> /dev/null 2>&1

   On shared hosting without Supervisor, add a second cron job instead:

   * * * * * cd /home/USER/foodifly && php artisan queue:work --stop-when-empty --max-time=55 >> /dev/null 2>&1

   Notifications then go out within about a minute instead of instantly.
3. Settings → General: check the currency, timezone, app name and logo, and fill in your support contacts, company name and address, and the Governing Law / Jurisdiction that your website's Terms of Service refer to.
4. Settings → Firebase & Push: upload your Firebase service-account .json and press Test connection. See Push notifications.
5. Settings → Maps & Location: add your Google Maps key and set the default map center. See Maps.
6. Settings → Payment Gateways: enter the keys for the methods you use and switch them on. See Payment gateways.
7. Realtime: create a Pusher Channels app and put its keys in .env. See Realtime.
8. Create your content: a fresh install has none. Add Cuisines, Delivery Zones (and their delivery fees), Banners, and optionally Coupons. Restaurants and riders sign up themselves and you approve them.
9. Run bash scripts/deploy.sh once more: every check at the end should show ✓.

🔑Demo data & accounts

To try the platform with sample data (8 restaurants with menus, 3 riders, 3 customers, 3 delivery zones, two weeks of orders, 2 coupons and 3 banners placed around your map center), use a development or staging copy:

php artisan migrate --seed          # or: php artisan db:seed --class=DemoSeeder
php artisan storage:link            # serves the demo photos

The demo photos are free Unsplash images downloaded once (about 4 MB). Without internet, or with SEED_DEMO_IMAGES=false, the demo is seeded without photos. The demo seeder refuses to run when APP_ENV=production, so seeding on a live server is safe. To remove the demo data and its photos again, without touching real data:

php artisan foodifly:demo-remove

Demo mode (a public preview site)

To run a live preview that anyone can try without being able to break it, turn on demo mode. Visitors can sign in to the admin panel, the apps, the website and the restaurant portal and look at everything, but nothing can be created, changed or deleted: every such request is refused with “This is a demo. Creating, changing and deleting data is turned off.” Signing in and out still works.

1. Install a separate copy for the preview and load the demo data (above), with SEED_DEMO_DATA=true if APP_ENV=production.
2. Turn demo mode on in .env, with the admin account you created in the installer:

   DEMO_MODE=true
   DEMO_ADMIN_EMAIL=admin@your-demo-domain.com
   DEMO_ADMIN_PASSWORD=the-password-you-set

3. Apply it: php artisan optimize. The admin sign-in page now shows the demo accounts (your Super Admin, plus the Manager and Support staff from the demo data) with a Use this account button that fills the form, and every admin page shows a “Demo” banner.

What demo mode restricts: every request that would create, change or delete something is refused with a "demo mode" message, for the admin panel, the API, the apps, the website and the portal. Reading is unrestricted. To turn it off, set DEMO_MODE=false (or remove the three DEMO_* lines) in .env and run php artisan optimize; the sign-in page then stops showing the demo accounts and everything is editable again.

🖥️Admin panel: modules

Sign in at https://your-domain.com/login. What each person sees depends on their role (see Staff & roles).

🛠️Settings reference

Admin → Settings has nine tabs. Changes apply to the website, the portal and the mobile apps without rebuilding anything.

👥Staff & roles

Admin access is controlled by roles. The installer creates your account as Super Admin (everything). Five roles are created for you:

Open Roles to see and change exactly which permissions each role has, to create your own roles, and to assign them. Add team members under Staff; when you create an account you can tick must change password so the person chooses their own at first sign-in.

📱Customer app

Folder: customer-app.

1. Configure the API address

flutter pub get
cp assets/.env.example assets/.env

Open assets/.env (a required file that is not tracked in git) and set:

Card payments need no key in the app: the publishable key comes from the payment method you set up in the admin panel.

2. Firebase (push notifications)

The package contains the demo project's Firebase files. Replace them with your own: create a Firebase project, register the Android and iOS apps with your package name, then replace android/app/google-services.json and ios/Runner/GoogleService-Info.plist. Upload the project's service account in the admin panel (Push notifications). All the address, Pusher and Firebase steps in one place: Connect the apps.

3. Your own app id, name and icon

• Package name: change applicationId in android/app/build.gradle.kts and the iOS bundle identifier in Xcode (Runner → Signing & Capabilities). If you also rename the Android code package (namespace in the same file), move MainActivity.kt to match. Both must match the app you registered in Firebase.
• App name: android:label in android/app/src/main/AndroidManifest.xml and CFBundleDisplayName in ios/Runner/Info.plist.
• Icon and splash: replace assets/branding/app_icon.png, then run dart run flutter_launcher_icons and dart run flutter_native_splash:create.
• Maps key for the native maps: the same GOOGLE_MAPS_API_KEY in assets/.env is read by the Flutter code and injected into the Android manifest and the iOS app at build time, so there is nothing to edit in the native files.

Before and after

Package name: android/app/build.gradle.kts, the iOS bundle identifier in Xcode, and the Kotlin package:

// before
namespace = "com.appifly.foodifly"
applicationId = "com.appifly.foodifly"
// after (your own id: lowercase letters, dots, no spaces)
namespace = "com.yourcompany.yourfood"
applicationId = "com.yourcompany.yourfood"

Then move android/app/src/main/kotlin/com/appifly/foodifly/MainActivity.kt to .../kotlin/com/yourcompany/yourfood/ and change its first line:

// before
package com.appifly.foodifly
// after
package com.yourcompany.yourfood

App name (shown under the icon): android/app/src/main/AndroidManifest.xml and ios/Runner/Info.plist:

<!-- before -->
android:label="Foodifly"
<key>CFBundleDisplayName</key><string>Foodifly</string>
<!-- after -->
android:label="Tasty Bites"
<key>CFBundleDisplayName</key><string>Tasty Bites</string>

API address (assets/.env, then build again):

# before
API_BASE_URL=
# after
API_BASE_URL=https://your-domain.com/api/v1

Google Maps key: only GOOGLE_MAPS_API_KEY=your-key in assets/.env. The rider and restaurant apps follow the same steps (their ids are com.appifly.deliveryman and com.appifly.foodifly_restaurant on Android, com.appifly.restaurant on iOS). Remember to register the new ids in Firebase (Connect the apps).

4. Run and release

flutter run                          # try it on a device or simulator
flutter build apk --release          # Android APK
flutter build appbundle --release    # Android, for Google Play
flutter build ipa                    # iOS, for the App Store

To make people update, raise the minimum version under Settings → App Version and turn on Force update.

Release signing

The download contains no signing keys or Apple team. Each app has to be signed with your own key before you publish it. Do this once per app (customer, rider, restaurant).

Android. 1. Create an upload keystore (Java's keytool comes with Android Studio). Run it inside the app's android/app folder and answer the questions:

keytool -genkey -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

2. Create android/key.properties (next to settings.gradle.kts) with the passwords you chose:

storePassword=your-keystore-password
keyPassword=your-key-password
keyAlias=upload
storeFile=upload-keystore.jks

storeFile is relative to android/app; an absolute path works too. android/app/build.gradle.kts reads this file for release builds. Without it, flutter build apk --release still works but signs with the debug key, which Google Play rejects.

3. Build with flutter build appbundle --release and upload the .aab to Google Play (turn on Play App Signing when asked).

iOS (needs a Mac, Xcode and a paid Apple Developer account):

1. Open ios/Runner.xcworkspace in Xcode (run flutter pub get and cd ios && pod install first).
2. Select Runner → Signing & Capabilities, tick Automatically manage signing and choose your Team. No team is set in the download.
3. Set your own Bundle Identifier and register it in App Store Connect and Firebase. Under Signing & Capabilities, keep Push Notifications and Background Modes → Remote notifications, and add your APNs key in the Firebase console.
4. Run flutter build ipa, then upload build/ios/ipa/*.ipa with Xcode's Organizer or the Transporter app.

In-app updates on Android

On Android, the apps can install a new version from inside the app through Google Play's in-app update feature (the in_app_update package):

• Optional update: when you publish a newer build on Google Play, the app downloads it in the background and then shows an Update ready message with a Restart button. It never restarts by itself. It asks at most once a day, and not again for a version the person declined.
• Urgent update: in the Play Console, set the release's in-app update priority to 4 or 5 and the app uses Google's full-screen update instead.
• Forced update (customer and rider apps): when Force update is on and the installed version is below your minimum, the Update required button runs Google's full-screen update first and opens the store page only if that is not possible.
• Only for Google Play installs: it does nothing for a sideloaded APK or a debug build, and nothing breaks. To try it, upload two builds with different version codes to Play's internal testing track, install the older one from Play, then publish the newer one.
• iOS has no such feature: the apps keep opening the App Store page.

🚴Rider app

Folder: rider-app. Set up exactly like the customer app, with these differences:

flutter pub get
cp assets/.env.example assets/.env

• Firebase: replace android/app/google-services.json, ios/Runner/GoogleService-Info.plist and lib/core/firebase/firebase_options.dart with your project's. (This app keeps its Firebase options in a Dart file too; the easiest way to regenerate it is flutterfire configure.)
• Package name: applicationId in android/app/build.gradle.kts and the iOS bundle identifier; app label in AndroidManifest.xml and Info.plist.
• Riders: a rider registers in the app with documents, then waits for approval under Admin → Riders. Only approved, online riders receive job offers. The rider app uses location while a rider is online; review the permission wording for your store listing.

👩‍🍳Restaurant app

Folder: restaurant-app. The kitchen on a phone or tablet: owners and staff take live orders without a computer. They sign in with the same accounts they use on the restaurant portal, and each staff role keeps its permissions. Menus, opening hours, team accounts and payouts are managed in the portal.

1. Configure the API address

flutter pub get
cp assets/.env.example assets/.env

That is the only setting. Pusher, the currency, the app name and the Terms and Privacy links all come from the backend.

2. Live orders and push notifications

• Live board (Pusher): nothing to set in the app. Once Pusher is set on the backend, new orders and status changes appear instantly with a sound alert and the header shows Live. Without Pusher the board refreshes every 15 seconds.
• Push (Firebase): new orders reach the owner's phone and the phone of every active staff member who can see orders, even when the app is closed. Replace android/app/google-services.json, ios/Runner/GoogleService-Info.plist and lib/core/firebase/firebase_options.dart with your project's (flutterfire configure writes all three). If firebase_options.dart is left empty the app simply runs without push.
• iOS: the Push Notifications capability is already set up (ios/Runner/Runner.entitlements). Upload an APNs key in Firebase, and test push on a real iPhone; the simulator does not receive a device token.

3. Your own app id, name and icon

• Package name: applicationId in android/app/build.gradle.kts (demo: com.appifly.foodifly_restaurant) and the iOS bundle identifier in Xcode (demo: com.appifly.restaurant). iOS bundle ids cannot contain underscores. Both must match the apps you registered in Firebase.
• App name: android:label in AndroidManifest.xml and CFBundleDisplayName in ios/Runner/Info.plist.
• Icon and splash: replace the images in assets/branding/ (app_icon.png, app_icon_foreground.png, splash_icon.png), then run dart run flutter_launcher_icons and dart run flutter_native_splash:create. The logo on the sign-in screen is assets/images/app_icon.png.
• Colors: lib/core/constants/app_colors.dart (main color: primaryOrange), shared with the customer app's design.

4. Run and release

flutter run
flutter build apk --release          # Android APK
flutter build appbundle --release    # Android, for Google Play
flutter build ipa                    # iOS, for the App Store

Sign in with a restaurant owner account, or a staff account the owner created under Team in the portal. The restaurant must be approved under Admin → Restaurants first.

🍽️Restaurant portal

Folder: restaurant-portal. This is how restaurant owners and their staff run their whole restaurant from a browser. For taking live orders on a phone or tablet they can also use the restaurant app.

1. Configure. Copy .env.example to .env.local and set NEXT_PUBLIC_API_URL to your API (e.g. https://your-domain.com/api/v1). The Pusher keys are optional (read from the backend); NEXT_PUBLIC_TIMEZONE is only a fallback, as the portal uses the timezone you set in the admin panel.
2. Install and run:

   npm ci
   npm run dev -- --port 3001        # development

3. For production: build and serve it behind HTTPS (for example Nginx proxying to Node). It listens on port 3336:

   npm run build
   npm run pm2:start                 # keeps it running with PM2 (or: npm start)

   PM2 comes with the portal (npm run pm2:logs, pm2:restart, pm2:stop). To use another port, set PORT in .env.local for PM2. NEXT_PUBLIC_API_URL is fixed when you build, so run npm run build again after changing it.
4. Allow it on the backend. In the backend .env add the portal's address to CORS_ALLOWED_ORIGINS and set FRONTEND_URL; set the Restaurant Portal URL under Settings → Email / SMTP so emails link to it.

Sizes and extras (dish options)

Open a dish (Menu → Edit) and use Options → Add group. A group is a question for the customer, such as Size or Extras:

• Required means the customer must choose before adding the dish. Leave it off for optional extras.
• Allow multiple turns the group from pick-one (sizes) into pick-any (extras).
• Each choice has a name and an extra price added to the dish's price (0 for none).

Customers see the choices in the app and on the website, the total updates as they pick, and the order shows the chosen options to the restaurant, rider and admin. The server prices every order from the restaurant's own list, so a customer cannot change a price. A dish can have up to 10 groups.

How restaurants join

1. A restaurant applies on the portal's Register page.
2. You review and approve it under Admin → Restaurants.
3. The owner signs in, builds the menu, sets opening hours and holidays, and invites staff (manager and kitchen roles) from Team. The live order board plays an alert for new orders.

The portal shows the logo and app name you set in the admin panel, and displays money and times in your currency and timezone.

🌐Customer website

Folder: customer-website. The website lets customers browse, order, track and manage their account from a browser.

1. Point it at your API, in one of two ways:

   • In .env (recommended when you run it with Node): copy .env.example to .env and set NEXT_PUBLIC_API_URL=https://your-domain.com/api/v1. The site then serves its settings from that value.
   • In public/config.js (also works on static hosting): set your domain and remove the // at the start of both lines:

     window.__FOODIFLY_API_HOST = 'your-domain.com';       // no http://, no /api/v1
     window.__FOODIFLY_API_PROTOCOL = 'https';

     This file is read when the page loads, so no rebuild is needed.

   With neither set, the site assumes the API is on the same host at port 8001, which is only right for local development. More in Connect the apps.
2. Install and run:

   npm ci
   npm run dev -- --port 3002        # development

3. Production:

   npm run build
   npm run pm2:start                 # keeps it running with PM2 on port 3002 (or: npm start)

   npm run build first pre-compiles the site's pages and switches to React's production build, so visitors' browsers do no compiling. Edit the .jsx files in public/ as usual; development (npm run dev) uses them directly. Serve it behind HTTPS and add its address to CORS_ALLOWED_ORIGINS in the backend .env.
4. Set your details in the admin panel (Settings → General): the footer shows your support contacts, and the Terms of Service and Privacy pages use your company name, address, support contacts and governing law from there. Until the governing law is set, the Terms refer to the operator's own country without naming one.

🔌Connect the apps

Four things tie your backend to the apps and websites. This page is the one place that lists them all. Do them in this order, after the backend is installed.

What goes where

1. The API address (base URL)

The API address is your backend's APP_URL plus /api/v1. If the admin panel opens at https://food.example.com, the API address is https://food.example.com/api/v1. Test it: open https://food.example.com/api/v1/app-config in a browser. You should see text starting with {.

• The three Flutter files start as .env.example: copy it to assets/.env first. Never put a trailing slash after /api/v1.
• In config.js the website wants the domain only: no https:// and no /api/v1. Add :8001-style ports only for a test server. In config.js remove the two // at the start of the lines you set.
• Use https. Phones block plain http addresses in release builds.
• Testing on a phone or emulator: localhost on the phone is the phone itself. Use your computer's Wi-Fi address (for example http://192.168.1.20:8001/api/v1), or http://10.0.2.2:8001/api/v1 for the Android emulator. Android allows plain http only for the hosts listed in android/app/src/main/res/xml/network_security_config.xml (localhost and the emulator), so add your computer's Wi-Fi address there as another <domain> while testing. Live builds should use https.

Let the browser apps talk to the backend

The portal and website run in a browser, so the backend must allow them. In the backend .env set:

FRONTEND_URL=https://www.example.com
CORS_ALLOWED_ORIGINS=https://www.example.com,https://portal.example.com

Use the exact addresses people type, separated by commas, with no trailing slash. Then run php artisan optimize. Mobile apps do not need this.

2. Pusher (live tracking and new-order alerts)

1. Sign in at dashboard.pusher.com → Channels → Create app. Pick the cluster nearest your customers. Open App Keys and copy app_id, key, secret and cluster.
2. Put them in the backend .env:

   BROADCAST_CONNECTION=pusher
   PUSHER_APP_ID=1234567
   PUSHER_APP_KEY=your-key
   PUSHER_APP_SECRET=your-secret
   PUSHER_APP_CLUSTER=eu

   Then run php artisan optimize. The secret stays on the server and is never put in an app.
3. That is all. The customer app, rider app, restaurant app, portal and website read the public key and cluster from /api/v1/app-config. The PUSHER_APP_KEY lines in the customer and rider .env files and NEXT_PUBLIC_PUSHER_KEY in the portal are optional; leave them blank, or, if you fill them, they must equal the backend values.
4. Check it: open /api/v1/app-config in a browser and look for "realtime". If it holds your key and cluster, Pusher is on. If it says null, the key, id or secret is missing, or BROADCAST_CONNECTION is not pusher, or you did not run php artisan optimize.

3. Push notifications (Firebase JSON files)

Firebase uses two different kinds of file. People mix them up, so keep them apart:

1. In the Firebase console create one project. Add an Android app and an iOS app for each of the three Flutter apps (customer, rider and restaurant), using the package name and bundle id you chose for each (applicationId / bundle identifier, see Customer app). They must match exactly.
2. For each app, download google-services.json and GoogleService-Info.plist and replace the demo files at the paths in the table. The rider and restaurant apps also need a new firebase_options.dart.
3. Open Project settings → Service accounts → Generate new private key to download the service-account .json.
4. In the admin panel go to Settings → Firebase & Push. In Step 1 upload that file. In Step 2 press Test connection. You want Server key uploaded and Google accepts the key to show as OK.
5. The same page shows Queue worker and Scheduler (cron). Both must be OK: pushes are sent from the queue. See After installing.
6. iOS only: in Firebase → Project settings → Cloud Messaging, upload an APNs authentication key from your Apple developer account. Without it iPhones receive nothing, while Android works.
7. Build the apps again so they pick up the new files.

Check that everything is connected

1. /api/v1/app-config opens in a browser and shows your currency.
2. You can sign in to each app and the website against your server (not the demo one).
3. Place a test order. The restaurant portal and the restaurant app ring and show it within a second or two: Pusher works.
4. Change the order status in the admin panel. The customer's phone shows a notification: Firebase works.

If something does not work

🔧Environment (.env)

The installer writes the backend's .env file for you. You can edit it afterwards; after any change run php artisan optimize (the configuration is cached). Put values containing spaces or # in double quotes. The defaults below are those of .env.example.

💳Payment gateways

Switch gateways on under Admin → Settings → Payment Gateways. Only enabled methods appear to customers. Cash on delivery and the customer wallet need no keys.

The platform confirms card payments by checking with the gateway when the customer returns from it, and bKash and the redirect gateways (Razorpay, SSLCommerz, senangPay, Paystack, Paymob, Mercado Pago, Flutterwave) through their callback URLs above, always by asking the gateway again before an order is marked paid. You do not need to register a webhook URL for Stripe, PayPal or Razorpay.

🔔Push notifications (Firebase)

1. Create a project at console.firebase.google.com.
2. Add an Android app and an iOS app for the customer app, the rider app and the restaurant app, using the package names and bundle ids you chose. Download google-services.json and GoogleService-Info.plist into each Flutter app (see Customer app and Rider app).
3. In Project settings → Service accounts, generate a private key (a .json file).
4. In the admin panel open Settings → Firebase & Push, upload that file and press Test connection.
5. Make sure the queue worker is running: pushes are sent from the queue.

For iOS you also need an APNs key uploaded in Firebase (Project settings → Cloud Messaging).

🔗External services and outbound connections

Foodifly contains no license check, no purchase-code verification and no usage reporting. It never sends anything to the author. The only outbound connections are the ones below; apart from OpenStreetMap, they go to services you set up, and only when you enable them:

Your Terms and Privacy pages should name the services you enable. See Customer website for the legal-page notes.

🗺️Maps

1. In the Google Cloud console, create an API key and enable Maps SDK for Android, Maps SDK for iOS and, for address search, Places API (New).
2. Put the key in Settings → Maps & Location, and in each app's assets/.env as GOOGLE_MAPS_API_KEY.
3. Set the default latitude, longitude and zoom to your city or country; the maps and the demo data start there.
4. Restrict the key by application id (and SHA-1 on Android) in the Google Cloud console. It is readable in any shipped app.

Without a Maps key the map screens stay blank; the apps can still be developed with DISABLE_MAP_PICKER=true (customer app).

Delivery route on the tracking map

While an order is on its way, the customer's tracking map draws the road route from the rider to the door, with the distance and time left ("5 min · 1.8 km away"), and the arrival time follows it. Before pickup it shows the planned route from the restaurant.

1. In the same Google Cloud project, enable the Routes API.
2. Under Settings → Maps & Location, add a key in Places API Key (or leave it blank to use the Maps key above) and keep Delivery route on the tracking map set to On. This key is used only on your server and never sent to the apps, so restrict it to the Routes and Places APIs and to your server's IP address.

The apps ask your server, not Google, and the server reuses a route for 30 seconds to keep Google usage low. With the setting off, no key, or if Google refuses the request, customers still see an estimated distance and time (marked with “~”) but no line on the map.

📧Email

Set your SMTP details under Settings → Email / SMTP (mail driver, host, port, encryption, username, password, From address and name) and use the test email button. Order, password-reset and notification emails are sent from the queue, so the worker must be running. The email templates can be edited under Notifications.

⚡Realtime (Pusher)

Live order tracking, new-order alerts for restaurants and job offers for riders use Pusher Channels.

1. Create an app at dashboard.pusher.com and note its App ID, Key, Secret and Cluster.
2. In the backend .env set BROADCAST_CONNECTION=pusher and the four PUSHER_APP_* values (all of id, key and secret are required; with any missing the app falls back to the log driver and live updates are off). Run php artisan optimize.
3. The website, the portal and the mobile apps read the key and cluster from the backend automatically. If you do set them in an app's .env, they must match the backend's.

🎨Customization

From the admin panel (no code)

• App name, tagline and logo, currency, timezone, support details, company details: Settings → General.
• Delivery fees, minimum order, commission, loyalty, tips, wallet limits and payout rules: Settings and Delivery Zones.
• Home banners, cuisines and the apps' intro slides: Banners, Cuisines, Onboarding.

Colors and branding in code

The website, portal and apps are in English. See Known limitations.

⬆️Updating

1. Back up your database and the .env file and storage/ folder.
2. Upload the new files over the old ones (keep your .env and storage/).
3. Run bash scripts/deploy.sh. It checks the server, installs packages, builds the admin assets, runs migrations (the site is in maintenance only for that step), refreshes the caches, restarts the queue workers and reports whether the worker, scheduler, Firebase key and currency are set up. It never seeds data.
4. The mobile apps only need rebuilding if their own code changed. To make people update, raise the minimum version under Settings → App Version.

Versioning and updates policy

• Versions are numbered major.minor.patch (for example 1.2.3). A patch fixes bugs, a minor release adds features and stays compatible with your data, a major release may need changes and says so in its notes.
• Updates are free for every buyer on CodeCanyon: download the new version from your Downloads page. Each release lists what changed in the Changelog, including any database migrations.
• Database changes always ship as migrations, so an update never needs you to edit tables by hand. Back up first, then follow the steps above.
• If you changed the code yourself, keep your edits in a copy and compare them against the new version before overwriting files.
• When you publish a new mobile app build, raise the minimum under Settings → App Version and use Force update only after the new app is live in the stores.

🔒Go-live checklist

• APP_ENV=production and APP_DEBUG=false.
• HTTPS on the API, the website and the portal.
• Demo data and demo accounts removed (php artisan foodifly:demo-remove) and a strong Super Admin password set.
• The queue worker and the cron scheduler are running (the Firebase & Push tab shows both).
• Gateways switched from test to live keys, and a real test order placed through each.
• Google Maps and Firebase API keys restricted to your app ids; your own Firebase files in every app.
• CORS_ALLOWED_ORIGINS lists only your website and portal.
• The web installer is locked (storage/installed.lock exists). Never delete that file on a live site.
• Database and storage/ backups scheduled.
• Legal pages reviewed by a lawyer and your governing law set.

🩺Troubleshooting

❓FAQ

•ℹ️ Known limitations

So you are not surprised, here is what version 1.0.0 does not include:

• No SMS. Notifications are delivered by push and email only; there is no SMS feature in this version.
• The restaurant app covers the kitchen only. Building menus, opening hours, team accounts, analytics and payouts are in the web portal.
• English only. There is no translation system; the apps, portal, website and admin panel are in English.
• One platform currency. No per-customer currency switching.
• Sign-in is by email and password. The backend has a Google sign-in endpoint, but none of the included apps or websites uses it.
• Mobile Pusher needs hosted Pusher. Self-hosted Reverb works for the web portal only.
• Regional gateways. bKash is Bangladesh-only; the other gateways work in the countries their provider supports. Test each in its sandbox before going live.

💬Support

What's included in support

• ✅ Answering questions about item features
• ✅ Fixing confirmed bugs reported by the buyer
• ✅ Assistance with item configuration

What's not included

• ❌ Custom feature development
• ❌ Installation service on your server
• ❌ Third-party service support (payment gateways, Firebase, Google Maps, Pusher, hosting)
• ❌ Assistance with items you have modified beyond the original source

Response time

Support responses are typically provided within 24–48 hours on business days.

📝Changelog

v1.0.0: Initial release

• Laravel 13 backend and admin panel with web installer, roles and permissions, reports, coupons, zones and commission rules.
• Customer, rider and restaurant Flutter apps (Android and iOS).
• Restaurant owner web portal and customer website (Next.js).
• Payments: Stripe, PayPal, Razorpay, bKash, SSLCommerz, senangPay, Paystack, Paymob, Mercado Pago, Flutterwave, cash on delivery and customer wallet.
• Live order tracking and alerts (Pusher), push notifications (Firebase), loyalty points and wallet.

📄Credits & licenses

Foodifly is built on open-source software. All of the libraries below allow commercial use and redistribution. Their licenses are included with each package in vendor/, node_modules/ and the Flutter package cache.

Backend and admin panel

Customer, rider and restaurant apps (Flutter)

The full list is in each app's pubspec.yaml; Flutter also shows every license inside the app via its license page.

Restaurant portal and customer website

Fonts, maps and images

• Fonts (Inter, JetBrains Mono, Poppins, DM Sans): SIL Open Font License 1.1. Inter and JetBrains Mono are bundled with the admin panel and this documentation; the mobile apps and the website bundle their own font files.
• Google Maps, Firebase, Pusher, Stripe, PayPal, Razorpay, bKash, SSLCommerz, senangPay, Paystack, Paymob, Mercado Pago, Flutterwave are third-party services with their own terms; the names and logos belong to their owners.
• Demo photos are free images from Unsplash, downloaded by the demo seeder only. They are not part of the package and should be removed from a live site (php artisan foodifly:demo-remove).