Custom Amiga Brain app issues/questions

I am building a custom app for the Amiga Brain (FastAPI + ReactJS) based on the template (GitHub - farm-ng/amiga-app-template) and I’ve successfully deployed the app. However, I am running into several issues:

  • The keypad does not appear on input fields. I’m just using components with with type “text” and “number”.
  • Is there a way to keep the app running in the background? I’d like to be able to run another app simultaneously.
  • Does the app get killed when the screen turns off? I’ve run into several cases where the server seemingly randomly shuts down on its own while the UI is still up.
  • Is there a way to visualize/interact with the Brain display for testing and debugging remotely?

Thank you for your help.

We recommend react-simple-keyboard for virtual keyboard input.

We plan to support backgrounding apps more cleanly, but in the meantime, you can achieve this by lightly abusing our service/app lifecycle in your manifest:

  • A service may run continuously and potentially serve multiple apps.
  • An app is started / stopped when the user selects / exits the application on screen. The launcher enforces that only one app is running at a time.

So, you can register your main application backend as a service to keep it always running. You’ll still need to register a dummy app if you want it to appear in the launcher UI. Your manifest will look similar to:

  "services": {
    "my-app-service": {
      "name": "my-app-service",
      "type": "service",
      "exec_cmd": "/mnt/managed_home/farm-ng-user-YOUR_USER_HERE/my-app/venv/bin/python3
      "autostart": true
    "my-app": {
      "name": "my-app",
      "type": "app",
      "exec_cmd": "/usr/bin/sleep inf",
      "deps": [
      "http_gui_port": 8042,
      "display_name": "My App"

No, the app process should continue to run and still be there when you wake up the screen. Debugging the App on the Launcher may help with troubleshooting.

Yes. First configure cross-network access, if you haven’t already. Then you have two options:

  1. Use a VNC viewer to interact remotely with the full Brain display.
  2. Remote access via web browser, similar to the linked instructions for Autoplot, but substitute the http_gui_port registered to your application.
1 Like

Awesome, this is very helpful. Thank you Patrick.

@patrick I’ve tried implementing the same app with Kivy, and run into this again - without any user input, my app just stopped and went back to the brain’s menu. The logs show that systemd stopped the app:

Feb 14 19:18:46[167656]: [INFO ] [GL ] BGRA texture support is available
Feb 14 19:23:05 systemd[4432]: Stopping “farm-ng-user- development service ”…
Feb 14 19:23:05[167656]: [INFO ] [Window ] exiting mainloop and closing.

This is problematic as my app starts async automation tasks that may need to run for hours. What might be causing this? Is there anything I can help check on my end?

Hi @genkikondo,

I’ll jump in alongside @patrick to help you through this :slightly_smiling_face:

This is problematic as my app starts async automation tasks that may need to run for hours.

If your app is starting a long duration background async task, would you consider setting this part up as a (headless) service that an app communicates with? This would be similar to what @patrick has recommended above, and an app with a frontend (kivy or react) could trigger this process to start through any communication framework, including gRPC, FastAPI, etc. depending on how you set up the service. A kivy app managing an hours-long duration background task is not ideal IMO, and this would allow you to start and stop your app to initialize, monitor progress, gather results etc. as a separate process from the background task.

What might be causing this? Is there anything I can help check on my end?

I’m not sure, it’s not something we’ve experienced yet. Does this coincide with any other event, such as the screen display turning off after periods of no activity? Does this happen when you manually launch your app from the command line as a python executable? Do you have sufficient logging in your application to confirm there is not something internal to the app causing it to crash?

Please share any other observations that may be relevant.

– Kyle

1 Like