Well in that would be serverless deployment right? The case where when my build completes it triggers deployment of the application, and the environment is provisioned by a configuration file as part of the source/build. You wouldn't want your application to have control over the OS, and a whole VM is more resource intensive to provision than a container within an VM. You woudln't want it configuring a network stack or an interface, or loading drivers and so on. You just want your dependencies to be where you need them and always be there.
> My original note was inspired by working with render.com's Docker mode, which is redundant because they already have a clean environment to run the package on, and having the extra layer makes it difficult to do simple stuff like use mounted discs.
Sure, but what happens when you want 3, or 4 instances running on the same machine? Well at best that's another script, at worst that requires human intervention during a deployment. As far as your mounted disk thing, im not sure I understand what trouble your running into, if it's a file-path, then it's usable by docker.
Ideally you provision the server itself to have a consistent state, and your applications (multiple of them) share the system state as much as possible. It's far more resource efficient that way. VMS generally need thick resource provisioning to make guarantees, that applications don't need or want.
ChipTuner
npub1qd…3fqm7
2025-05-14 20:21:15
in reply to nevent1q…8elp
Author Public Key
npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7Published at
2025-05-14 20:21:15Event JSON
{
"id": "2b35d40e5a7a37ce40fce0279f52c9782d7d0d32ceb9c5134fe2d6489a30b218",
"pubkey": "036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58",
"created_at": 1747254075,
"kind": 1,
"tags": [
[
"e",
"2692061bce944057cb84d0ca38f4e55b3963fffbe7696310470f2aacfaa6d33e",
"wss://nostr.land/",
"root"
],
[
"e",
"4176918f24aa5628900dca6b2e9d3c0b90604016469735139df8187b066e32e7",
"wss://nos.lol/",
"reply",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
],
[
"p",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58",
"",
"ChipTuner"
],
[
"p",
"3e0f744d54acee8e2c7fea0be2c4cf99c089a4faa83ff7ccc3d0d9f1b59a3463",
"",
"lkraider"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
]
],
"content": "Well in that would be serverless deployment right? The case where when my build completes it triggers deployment of the application, and the environment is provisioned by a configuration file as part of the source/build. You wouldn't want your application to have control over the OS, and a whole VM is more resource intensive to provision than a container within an VM. You woudln't want it configuring a network stack or an interface, or loading drivers and so on. You just want your dependencies to be where you need them and always be there. \n\n\u003e My original note was inspired by working with render.com's Docker mode, which is redundant because they already have a clean environment to run the package on, and having the extra layer makes it difficult to do simple stuff like use mounted discs.\n\nSure, but what happens when you want 3, or 4 instances running on the same machine? Well at best that's another script, at worst that requires human intervention during a deployment. As far as your mounted disk thing, im not sure I understand what trouble your running into, if it's a file-path, then it's usable by docker. \n\nIdeally you provision the server itself to have a consistent state, and your applications (multiple of them) share the system state as much as possible. It's far more resource efficient that way. VMS generally need thick resource provisioning to make guarantees, that applications don't need or want. ",
"sig": "bd078565860434e4dc9e78c596dfd99ce47d9c4373049e94b9f8ab0d3d3409a828fcd3d30e455ffd617ab00ea586ec0e561b40bf73234359b6c365058251db2e"
}