VPS providers, like digitalocean have a relatively small limit on the size that the ignition.json file can be (loaded in main.tf "user_data" key). Instead load a minimal ignition.json that just includes a link to the full ignition.json file hosted on nassella.
Question, how to handle this for locally hosted Nassella, as it does not have a server running and would need some sort of reverse-proxy to serve a file. Maybe upload it to a backblaze bucket first? ngrok?
The control plane server would need do something like create a hashmap of instances and corresponding igntion.json's along with the instance ID. Then only serve the ignition.json if a request contains matching authorization and instance ID headers. After serving it, the key and corresponding config should be deleted from the hashmap.
Alternatively: can we just gzip the main ignition.json file and have a skeleton ignition.json use config.replace to load the compressed file? --update, that won't work as we can only load one file
another idea: just compress and b64 encode the app tree and use a oneshot systemd service to extract it
VPS providers, like digitalocean have a relatively small limit on the size that the ignition.json file can be (loaded in main.tf "user_data" key). Instead load a minimal ignition.json that just includes a link to the full ignition.json file hosted on nassella.
Question, how to handle this for locally hosted Nassella, as it does not have a server running and would need some sort of reverse-proxy to serve a file. Maybe upload it to a backblaze bucket first? ngrok?
The control plane server would need do something like create a hashmap of instances and corresponding igntion.json's along with the instance ID. Then only serve the ignition.json if a request contains matching authorization and instance ID headers. After serving it, the key and corresponding config should be deleted from the hashmap.
Alternatively: can we just gzip the main ignition.json file and have a skeleton ignition.json use config.replace to load the compressed file? --update, that won't work as we can only load one file
another idea: just compress and b64 encode the app tree and use a oneshot systemd service to extract it
Possible example of how to do this:
```
{
"ignition": {
"version": "3.4.0",
"config": {
"replace": {
"source": "https://example.com/full-config.ign",
"httpHeaders": [
{
"name": "Authorization",
"value": "Bearer xxx"
},
{
"name": "X-Instance-ID",
"value": "instance-xxx"
}
],
"verification": {
"hash": "sha512-..."
}
}
}
}
}
```
tjhintz
added this to the v1 release milestone 2026-07-09 22:32:46 +00:00
tjhintz
added this to the nassella project 2026-07-09 22:32:46 +00:00
tjhintz
moved this to To Do in nassella on 2026-07-09 22:32:51 +00:00
tjhintz
moved this to In Progress in nassella on 2026-07-11 00:59:17 +00:00
tjhintz
changed title from Move ignition.json to be loaded externally via HTTPS to Resolve ignition.json being too large for digitalocean (over 64kb)2026-07-11 00:59:41 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
VPS providers, like digitalocean have a relatively small limit on the size that the ignition.json file can be (loaded in main.tf "user_data" key). Instead load a minimal ignition.json that just includes a link to the full ignition.json file hosted on nassella.
Question, how to handle this for locally hosted Nassella, as it does not have a server running and would need some sort of reverse-proxy to serve a file. Maybe upload it to a backblaze bucket first? ngrok?
The control plane server would need do something like create a hashmap of instances and corresponding igntion.json's along with the instance ID. Then only serve the ignition.json if a request contains matching authorization and instance ID headers. After serving it, the key and corresponding config should be deleted from the hashmap.
Alternatively: can we just gzip the main ignition.json file and have a skeleton ignition.json use config.replace to load the compressed file? --update, that won't work as we can only load one file
another idea: just compress and b64 encode the app tree and use a oneshot systemd service to extract it
Possible example of how to do this:
Move ignition.json to be loaded externally via HTTPSto Resolve ignition.json being too large for digitalocean (over 64kb)seems like just compressing the /app tree will fix this and should make it so we can add many more apps without it becoming a problem