Thanks for the feedback! I will keep this on the list.
We are starting to move to optimization and the 1st on the team’s priority list is ram and they have nailed it 
Let’s move down the list and get this cleaned up as well!
I can beta test in Azure. I can test deploying this my cloud infrastructure.
1 Like
I am also interested in beta testing. Please include me also.
2 Likes
Would be awesome if you could add me to the list 
thank you cheers clyde!
2 Likes
i wouldn’t mind a peek, to see how it can be used with my non-cloud local build setup:
2 Likes
How did I miss this before? I’m interested in helping with beta testing for local cloud. I’m a full-time web developer by day, tinkerer by night.
2 Likes
Add me to the list… I’ve got a spare raspberry pi lying around that would be a great little hub to play with…
2 Likes
Local cloud? What I need! If you want, include me as a beta tester.
2 Likes
Hi! Can you add me to the list as well
lol its getting a bit silly now, might as well stick everyone on the list!
@kennethlimcp @Dave
Hey guys. By the looks of it, almost everybody who sees the possibility of a beta wants to be included. Would it be stupid of me to say that you should just open the beta to everybody, but with a big warning that it’s a beta, and shouldn’t (yet) be relied on? This way everybody gets the opportunity to play around with it, and maybe help find some bugs, even minor ones.
Everybody knows Spark as a whole is a project under continues work, and I think they wouldn’t mind so much if the local cloud would be as well.
Just a thought though, won’t argue if you disagree, you’re doing a great job!
Hey @Moors7, it’s not in my capacity to decide how wide an audience gets to beta and how many people on the list I manage gets into the program.
All I’m doing during my free time is to help the 
community get as much support and interaction as they can 
With regards to beta, the whole idea is to have a focus group with people who are not only able to help test, but more importantly, inform the team of bugs and the possible fix.
If everyone gets involve, we might end up:
-
Helping people with installation problems
-
Bombarded with feature requests
-
Having too much feedback as the software is still unstable
-
Making people more frustrated and end up thinking that the local cloud isn’t awesome
That’s what I really think the beta should differentiate and help speed up the delivery of local cloud instead of slowing down the process!
Thanks for your inputs @Moors7, always happy to hear community inputs and exchanging pointers
1 Like
If you put it like that, then I guess there’s nothing to argue about. Seeing the list grow (almost) daily, made me think everybody couldn’t wait to start, hence my comment. Seeing your arguments, along with your experience, I guess it’s indeed better to limit it somewhat.
Thank you for all your efforts, you’re a great help for the whole community!
Looking forward to the cloud
1 Like
Just a general question: Will there be a capability for a local cloud server to pass information up to the “official” Spark Cloud? That could be convenient for a variety of use-cases. For instance, if you wanted some information to be “public” vs “private”, or if you wanted to log lots and lots of detailed data in the local cloud, and send a smaller set of aggregate data up to the public cloud.
2 Likes
Hi @dougal,
That’s actually something I’ve been thinking a lot about over the last year. Especially, like you said, if you consider if you want software external to your local network to get some things and not others, like, I only want to unlock my door when I’m on my local network, but I want to check and make sure my door is locked when I’m not home, etc.
The initial release of the local cloud won’t have these features due to time constraints, but I am really interested in building them… There are some really fun use cases for what we’re calling the “Federated” cloud… 
Thanks,
David
3 Likes
Sure, I understand that. I didn't necessarily expect that to be a feature from the start, but I'm glad to know you were already thinking about it. And of course, once the code is public, maybe some of us community members can contribute to that development.
Definitely! I was thinking granular access permissions per core for things like variable / function access, flashing new apps, publishing events, etc, and an optional system for registering a local cloud against a user account. Eventually I also want to build an optional way to toss cores between local / global clouds via the API, so you can do it from the web IDE, and to prevent the old “to which server is my core connected” problem…
Thanks,
David
1 Like