Skip to content

Latest commit

 

History

History
66 lines (50 loc) · 2.47 KB

File metadata and controls

66 lines (50 loc) · 2.47 KB

Deployment

Web FTP target

  • Host: ftp.connectio.com.au
  • Port: 21
  • Username: [email protected]
  • Password: stored in macOS Keychain as generic password service dreamflowCommandForFlutterFlow.ftp.

Retrieve password for agent-driven deployment:

security find-generic-password -s dreamflowCommandForFlutterFlow.ftp -a [email protected] -w

Build and upload dist/:

npm run build
python3 scripts/deploy_ftp.py

scripts/deploy_ftp.py mirrors dist/ onto the FTP account root: it uploads every local file, then prunes any remote file that no longer exists locally, scoped to the directories dist/ itself manages (the root, api/, assets/). This exists because Vite content-hashes built assets (index-<hash>.js), so a stale bundle from the previous build would otherwise sit on the server forever. It never lists or deletes a remote directory that has no local counterpart. Use --dry-run to preview without changing the server.

FlutterFlow custom-class deploys

FlutterFlow's VS Code extension supports editing existing standalone Custom Code Files through syncCustomCodeChanges (CodeType.CODE_FILE, wire type "C"). That endpoint looks up an existing FFCustomCodeFile by filename and does not create a missing entity.

For a new CustomClass, the web app calls the Cloud Run AI-DSL runner to upsert the complete class source with addCustomClass or updateCustomClass. That class file is then excluded from the extension-style sync; the remaining bundle files and dependency changes still use syncCustomCodeChanges. Existing code files that appear in project exports use the normal sync path directly.

The production runner defaults to:

https://ccc-ffai-runner-y5cyj3473a-uw.a.run.app/deployCustomClasses

Override it at build time with VITE_FLUTTERFLOW_CLASS_PROVISION_ENDPOINT. VITE_FLUTTERFLOW_DSL_DEPLOY_ENDPOINT remains accepted for compatibility. Deploy the runner with:

PROJECT_ID=low-code-connect REGION=us-west1 ./scripts/deploy_cloud_run_ffai.sh

pubspec.yaml dependency sync

Deploys never synthesize a pubspec.yaml. FlutterFlow treats the pushed serialized_yaml as the project's complete dependency set, so the app exports the project (exportCode), reads the real pubspec.yaml out of the archive, adds only the packages the generated code needs, and pushes the merged file back. If the export cannot be read the deploy fails rather than risk replacing the project's dependencies.