@robi Indeed, I did mention grav-system-info.yaml 
However, that file is a generated when you click Export YAML under Configuration > Info.
IOW, I don't think you can edit it and affect the system.
I diid add opcache.revalidate_freq: "60s" to php.ini found at /app/data/. But this didn't speed things up.
@robi Forgive the basic question, but which .yaml file?
I'm using the copy page button in Admin2 to copy:
It takes 12-16 seconds before I can edit the new copy on the Dockerized version.
In contrast, on the same server, the LAMP version takes ~7 seconds.
The demo server was faster, but yielded similar results (i.e., faster on on the LAMP install).
Thank you!
@jdaviescoates Yes, I tried …
… but no difference.
Copying a page in Admin2 is still slow.
Thanks for your reply!
Update: just re-tested on the Docker install, and the I/O amounts are now similar to the LAMP install.
However, copying a page in the GUI is still slow.
@robi Thanks for the reply! No, I haven't changed the opcache.revalidate_freq as I don't know how. If there is a way to do that in Cloudron, please let me know.
CPU usage for both is okay -- but the Disk I/O is quite different: 4.6 GB / 9.6 GB for Docker and 128 MB / 436 MB for LAMP:
Docker:
LAMP:
Would the following making any difference?
grav-system-info.yaml from the Dockerized install has opcache.revalidate_freq: "2s"
while
grav-system-info.yaml from LAMP install has opcache.revalidate_freq: "60s"
?
@nebulon Thanks for the reply.
Yes, both apps are installed and using the same disk.
Good to know the Grav package is also using Apache.
Quite a mystery why there is a difference in speed then! 
@robi – Good idea!
Yes, after installing Grav and LAMP (and then Grav on top of that), LAMP/Grav is still faster on the demo server.
Update: Installing Grav on the Cloudron LAMP App yields faster copy times (about twice as fast).
Thus, perhaps it is something related to the Dockerization of it?
hdparm -Tt /dev/vda4 yields:
/dev/vda4:
Timing cached reads: 9658 MB in 1.99 seconds = 4846.98 MB/sec
Timing buffered disk reads: 896 MB in 3.00 seconds = 298.61 MB/sec
Wait time (wa) using vmstat 1 is 0 or 1.
These numbers look good.
I'll continue to research and report back if I discover anything.
Thanks again for your help!
@james Thank you. I totally understand that this is nearly impossible to diagnose. Feels like such an odd issue.
Anyhow, not sure which aspect of the browser console would be helpful, but the long wait times are confirmed:
Further, here is the output of cloudron-support --troubleshoot:
Vendor: Red Hat Product: KVM
Linux: 5.15.0-185-generic
Ubuntu: jammy 22.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz x 4
RAM: 8127812KB
Disk: /dev/vda4 16G
[OK] Root disk usage is OK (82%)
[OK] Memory usage is OK (53%)
[OK] Clock is NTP-synchronized
[OK] node version is correct
[OK] IPv6 is enabled in kernel. No public IPv6 address
[OK] docker is running
[OK] docker version is correct
[OK] MySQL is running
[OK] netplan is good
[OK] DNS is resolving via systemd-resolved
[OK] unbound is running
[OK] IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[SKIP] IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip — no public IPv6 address
[OK] IPv4 HTTPS to auth.docker.io/token
[SKIP] IPv6 HTTPS to auth.docker.io/token — no public IPv6 address
[OK] IPv4 HTTPS to acme-v02.api.letsencrypt.org
[SKIP] IPv6 HTTPS to acme-v02.api.letsencrypt.org — no public IPv6 address
[OK] nginx is running
[OK] dashboard cert is valid
[OK] dashboard is reachable via loopback
[OK] No pending database migrations
[OK] Service 'mysql' is running and healthy
[OK] Service 'postgresql' is running and healthy
[OK] Service 'mongodb' is running and healthy
[OK] Service 'mail' is running and healthy
[OK] Service 'graphite' is running and healthy
[OK] Service 'sftp' is running and healthy
[OK] box v9.2.0 is running
[OK] Dashboard is reachable via IPv4 (https://my.indychinesechurch.org)
[SKIP] Dashboard IPv6 reachability — no public IPv6 address
[SKIP] Domain expiry check — whois not installed; run 'apt install whois' to check
======== Summary ========
PASS: 26
WARN: 0
FAIL: 0
SKIP: 5
(This is a stretch, but I'm not sure where else to post.)
Copying a page in Grav 2.0/Admin 2.0 is slow (~12 seconds).
The Grav support forum suggests it is not a Grav issue, but may be a server/network issue.
From the log below (which shows long POST and PATCH requests of 3 and 6 seconds respectively), is there anything that would suggest this is related to how Cloudron configures things?
Jul 09 08:01:10 149.154.20.112 - - [09/Jul/2026:12:01:10 +0000] "GET /api/v1/pages?children_of=%2F&sort=order&order=asc&per_page=200&page=1 HTTP/1.1" 200 2599 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:11 149.154.20.112 - - [09/Jul/2026:12:01:10 +0000] "POST /api/v1/pages/test/copy HTTP/1.1" 201 6063 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:14 - - - [09/Jul/2026:12:01:14 +0000] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.58 (Ubuntu) mod_perl/2.0.13 Perl/v5.38.2 (internal dummy connection)"
Jul 09 08:01:17 149.154.20.112 - - [09/Jul/2026:12:01:11 +0000] "PATCH /api/v1/pages/test-2 HTTP/1.1" 200 6069 "https://examplesite.org/admin/pages/edit/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Jul 09 08:01:23 - - - [09/Jul/2026:12:01:20 +0000] "GET / HTTP/1.1" 302 - "-" "Mozilla (CloudronHealth)"
Jul 09 08:01:23 149.154.20.112 - - [09/Jul/2026:12:01:17 +0000] "GET /api/v1/reports/twig-content/page?route=%2Ftest-2 HTTP/1.1" 200 80 "https://examplesite.org/admin/pages/edit/test-2" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5 Safari/605.1.15"
Correct.
In addition, I'm now noticing that Grist has been switched to the Community Edition.
We were previously on the Full Grist (which allows automations).
Perhaps that is why email stopped working?
Also, clicking "Switch to Full Grist" leads to a button that says "Restart Grist" -- but then restarting does nothing.
There's a flurry of activity when I trigger an email.
Here is a lightly-edited excerpt:
Jul 01 16:30:56 2026-07-01 20:30:56.210 - info: DocWorkerMap.setWorkerLoad workerId=testDocWorkerId_8484, load=0
Jul 01 16:30:57 2026-07-01 20:30:57.066 - debug: activeDocMethod org=docs, email=sample@email.com, userId=5, altSessionId=ns7Xdi6QPxD42QR85w7bF4, age=49, clientId=732baeda16c446d0, counter=52, access=owners, docId=7YTNCBZanCY9QLi1JKzzHY, docMethod=applyUserActions
Jul 01 16:30:57 2026-07-01 20:30:57.074 - debug: NSandbox pyCall sandboxPid=113, flavor=pyodide, command=undefined, entryPoint=(default), docId=7YTNCBZanCY9QLi1JKzzHY, funcName=apply_user_actions, loadMs=5
Jul 01 16:30:57 2026-07-01 20:30:57.081 - debug: _doApplyUserActions: stored #0 [0]: ['UpdateRecord', 'Master_Grid', 576, {Reminder: 1782864000}]
Jul 01 16:30:57 2026-07-01 20:30:57.089 - info: ActiveDoc fetchQuery {"tableId":"Master_Grid","filters":{"id":[576]}} (regular) access=owners, docId=7YTNCBZanCY9QLi1JKzzHY
Jul 01 16:30:57 2026-07-01 20:30:57.109 - debug: NSandbox pyCall sandboxPid=113, flavor=pyodide, command=undefined, entryPoint=(default), docId=7YTNCBZanCY9QLi1JKzzHY, funcName=fetch_table, loadMs=20
Jul 01 16:30:57 2026-07-01 20:30:57.110 - info: ActiveDoc fetchQuery -> 1 rows, cols: name, address, birthday, access=owners, docId=7YTNCBZanCY9QLi1JKzzHY
Jul 01 16:30:57 2026-07-01 20:30:57.111 - info: WebhookQueue: Processing triggers numTriggers=1, numRecords=1, docId=7YTNCBZanCY9QLi1JKzzHY
Jul 01 16:30:57 2026-07-01 20:30:57.117 - info: WebhookQueue: Generated events from triggers numEvents=1, numTriggers=1, numRecords=1, docId=7YTNCBZanCY9QLi1JKzzHY
Jul 01 16:30:57 2026-07-01 20:30:57.118 - info: WebhookQueue: Total number of webhook events generated by bundle numEvents=1, docId=7YTNCBZanCY9QLi1JKzzHY
Jul 01 16:30:57 2026-07-01 20:30:57.123 - info: ActiveDoc applyUserActions done startTs=1782937857067, start=2026-07-01T20:30:57.067Z, org=docs, email=sample@email.com, userId=5, altSessionId=ns7Xdi6QPxD42QR85w7bF4, age=49, clientId=732baeda16c446d0, counter=52, access=owners, docId=7YTNCBZanCY9QLi1JKzzHY, mark_waitForInit=22, actionDesc=[['UpdateRecord', 'Master_Grid', 576, {Reminder: 1782864000}]], mark_accessRulesPreCheck=1, mark_dataEngine=8, mark_accessRulesCheck=14, actionNum=735, linkId=0, otherId=0, numDocActions=1, numRows=1, numBytes=358, mark_docStorageTxn=15, mark_docStorage=21, mark_processBundle=21, docRowCount=1339, mark_updateRowCount=54, mark_accessRulesApplied=54, mark_sendDocUpdate=55, mark_notifySubscribers=55, mark_accessRulesFinish=55, resultDesc={actionNum: 735, actionHash: '70b1e6b4b19e94161c10b0399a4b7d0818c8e5a2a8e96a29857981565dabbf40', retValues: [null], isModification: true}, mark_end=56
Jul 01 16:31:00 2026-07-01 20:31:00.127 - debug: Auth[GET]: ourwebsite.com / customHostSession=, method=GET, host=ourwebsite.com, path=/, org=, email=anon@getgrist.com, userId=1, altSessionId=icCNm3eSA9zJFWN52GVnfq
Did something change with yesterday's update?
I can trigger an email to be sent out by Grist, but our mail server is not showing any email actually being sent out.
True, but Admin 1 does not look to be compatible with Grav 2 (which was made to work with Admin 2).
Further, at least from my understanding, there are other issues that arose for our site that would have been mitigated through the migration process.
Grav 2.0 is a significant upgrade and really requires a migration (rather than the upgrade which Cloudron does).
https://getgrav.org/migrate-to-2 may be of help to Cloudron team.
However, when I tried to use their migration plugin, I got the following error:
Migration kickoff failed: Webroot is not writable: /app/code
So this is just an FYI that Cloudron users that use Grav may face some initial challenges with Grav 2.0.
It works! Thank you!