A server provisioning service for Ruby on Rails, Laravel and static based projects, with zero downtime deployments including your usual mix of common PHP CMS platforms like Craft CMS or Wordpress.
This project, for now, is on hold. Last year was difficult, and working with servers became a little bit too depressing on top of everything else. More to be announced when I can. Picard might become something else ✌️❤️ For now, perhaps check out Sublime Ads which is launching in February 2021.
Better late than never, however my little server management project, Picard.sh, is now "on hold". Last year was too depressing, and working with servers was also depressing - so I had to move on from it.
I don’t know what I’ll do with it, perhaps server monitoring...
Continuing from the registration section, I started working on the Login part last week. There were a few more moving parts here as I had to cover both a password login and of course a magic link login. As I was completing it and testing it there were a few edge cases that had to be dealt with also.
You start with your normal email form:
Nothing special. I’m not really a fan of having email only first and always prefer when there is a password field also. However, as we have to deal with both passwords and magic links, this was for the best.
Pressing “Go” will check the email to see if it’s valid and that the account is active. Next it will check what type of login you have. That means either magic links or passwords. Here is the magic link screen:
I’ll probably change the wording here. Once you receive the email, you tap/click on it and you’ll be on your way. Magic links are only valid for 15 minutes.
For password logins I will show you the below:
Easy enough to navigate. There is an addition of a “use magic link” button. This will send a magic link your way, just in case you forget your password. This also sets your login method to be magic link only until you change your password.
Once you’re all confirmed with email, password and/or magic link, you will have to enter your one time passcode:
I still don’t have back up codes set up and I’m thinking of doing something else to facilitate that, so for now I just say to email me. I could trigger the two factor set up on the account once again.
To be honest, you shouldn’t be loosing your data - but I appreciate that it can happen - so I will work something out to make that less painful.
As with everything I tried to think of a few edge cases along with the ones I came across. For example, when you register there are certain steps to take - but perhaps the user didn’t finish all of them. In that case, depending on the registration step you were at, it will ask you for details that you certainly know for example your email and password, but then it will go ahead and redirect you to the correct registration step to continue. As you probably don’t have any data/servers set up, unless you have finished the sign up, I think this is a good compromise.
All new accounts start with a magic link login, so even if you haven’t chosen you will still be able to login and continue where you left off.
I still need to implement failed logins attempts to disable the account. The database already includes the counter column, so it should be easy to add that.
That’s it for now on registration and login. I would call it feature complete. The next task is to think about the Dashboard section - I didn’t have too much brain capacity to think about that just yet.
I wanted to write this post last week; kinda weird times at the moment. I’ll try and keep it more regular in the coming weeks.
Thanks for reading, and if you have any input… let me know!
Just completed the login section and logic for Picard.sh. Pretty happy that it's done now. Going to do a write up tomorrow at some stage. Hoping to use it on another project, so I took care to get it right.
Quick update on Picard.sh: Completed the login flow for magic links. Was harder, but certainly more entertaining, than I initially thought. Tomorrow I’ll try and complete the “password” login flow. Two Factor auth already working too.
Good progress.
Spent an hour this morning to add “Team” support for Picard.sh. Kept it simple for now as I don’t intend to role out with it on launch - just happy it’s there now than later.
Yesterday, I exclusively spent the day on finishing the registration process for Picard. Just to recap from the last blog post, I wanted to give users a choice of either a password login or a magic link. I think that gives users the flexibility.
Magic links are good, but if you want a password you can do that too. Personally I prefer magic links because I don’t need to know about the password at all, and as they are one time use - it’s more secure (so I believe… “A password you don’t know is the best password”). However I totally get it.
So, you can do that. Here is the password screen:
Nice and simple.
Note that I don’t enforce specific rules, they can be as long as you want… or as short as you want. However, here comes the great part. All passwords (or specifically part of the password hash) is sent to HaveIBeenPwned (https://haveibeenpwned.com/Passwords).
Note that no full password is ever sent to their API at all! It is only the first few parts of the password hash. This in turn returns results of passwords that have been used in the past during known breaches. The results bring back the last part of the password hashes that started with the first 5 character hash I sent through. This way I can check locally if any of them match your password. If so, Picard will reject your password and deems it unsafe. If you’re interested, 1Password uses the same practice to check against bad passwords.
I think that’s the best type of password enforcement rules I can think of. Perhaps I’ll go a step further and specify some basic rules. Although I always found it off putting when I went to a site that had several bullet points of bad advise. “Must contain 8 characters but not more than 30” blah blah blah.
I guess I could suggest a password that they can use… so that the user doesn’t have to take a wild stab at it. Although Safari is pretty good about suggesting passwords.
Anyway, I think having it hooked up with the above is a great combo.
Of course I also have a double check in place so that you confirm the password you typed beforehand is the same:
On top of that, it brings us nicely to the next point!
I made the decision that Two Factor Authentication is mandatory for both magic link logins and password logins. At the end of the day we are dealing with servers, and most likely customer data. So I’m making it mandatory that you set it up as you register. There is no way around it.
You’re going to be dealing with data in a database, which most likely includes customer data. To avoid, and fend off, any unauthorised access to your Picard account you’ll be required to authorise certain actions with your one-time passcode. That includes logging in, or other account options.
Here is an example screen running locally on my machine:
Each QR code is generated as your account is created. Once scanned, you will have to submit a valid token in order to proceed. That is rendered via SVG and is never saved locally as an image!
This was quite fun to do.
Initially I wanted this option only mandatory for password logins, but it dawned on me that everyone should benefit from this. In a way it gives me less logic to write later on if you did want to enable it for magic links.
I have a plan, in my head, about account recovery if you did ever loose access. Although it’s the 21st century, and you should hopefully be tech savvy about things like this (considering you’ll be running your own servers).
Anyway, I’m happy with the way it worked out and I prefer better security practices from the start. I worked with many clients, past and present, and it scares me how some of them secure their stuff. Just like flying aeroplanes… you never know who is going to be flying with you up front (trust me, I know). So, just a friendly hand from one developer to another to do the right thing from the start.
Pain point? Nope. Security is paramount!
After you have confirmed your token, you’ll go to the “Thanks” page:
I’m not sure if I will add this step closer to release… it’s there for now. It serves a few purposes.
One is to say “thank you”, the other to say “Hey, you have an AWESOME 30 day trial” (unlike everyone else out there) and to send a confirmation email out if your email hasn’t previously been verified (basically everyone that didn’t come from the “pre-register” phase).
For the next step I need to work on the login phase of the project, which includes several things like magic link emails and forgotten password links etc.
Hoping I have that done by next week at some stage.
I’m always thinking about the “dashboard” design (called “Bridge” for now)… it’ll certainly be different than what you see at the moment during registration and login.
Another thing I want to work on is much better wording. I think it’s OK at the moment, however it can be improved. I think 40% of my commits to the project are word changes!
Anyway, thanks for reading. More very soon.
You can find Picard.sh here and sign up on the invite list.
It's totally been overdue, but here I am with an update on Picard.
I'm not going to lie, I let this slide a bit after some pressure on getting Gluon out the door and a fair amount of client projects. So, here I am with some progress.
Let's get to it.
I spent some time, over the weekend, to work on the registration process. There were a few screens designed already, but they had zero functionality.
The database design was already complete from my past self so all I had to do was write the code and make it work.
It's not complete yet, however it surely is getting there.
Registration is always weird and everyone does it differently. For Picard I wanted something that was quick to get in to, yet be safe to you. Managing your own servers can be tricky and using a third-party, like Picard, sure makes life easier.
However, with convenience comes responsibility.
When you're running a server that usually means you also keep personal information on it. That means that you should stay secure from sign up to deployment. As Picard acts as a front end to all your servers, I don't just want to allow the user to set any password they wish and be done with it. That just opens up headaches with keeping your account secure.
With that in mind, here is the flow of registration I have in mind:
The first two are easy, just set an email and then set your name. For email signup, during the beta, it will check if you have pre-registered or not. Only valid emails and pre-registration tokens can be used during pre-registration. You will get an email with that once I send out the first invites. If you want to set a different email during that process, you're more than welcome to.
Here is a screenshot:
Easy enough to get your started. Not shown is some extra text in the description, when using a pre-register invite link, saying that a different email can be used. You can see a screenshot of that here.
Next up is the Name field, keeping it simple:
This is just to keep it all nice and human. That name can be anything that means something to you. Your actual name is a good start. It will play a role later on. It's a mandatory step.
To note, all data is encrypted in the database, here is a preview from my local machine:
Note that my local, staging and production database all have different encryption keys.
Once that is set, we come to the password selection screen. This is slightly different than what you're used to normally, and I give you a choice of what you want to do.
Two options:
Personally I prefer magic links, but I totally see the need to set your own too. So here I give you an option.
If you choose magic links for log-in, you will receive a link via email every time you want to log into Picard. A great side effect here is that you will never know your password... and it constantly changes - so it's never the same.
Some of you prefer to set your own password, and I totally get it! In this case, you will go ahead and enter your own password during registration. Here I am planning to also check if the password hasn't been pwned before and if it's secure. That means I'll check the database at Have I Been Pwned before allowing you to proceed. 1Password also uses this feature to check against "pwned" passwords. To note, the password is never sent to Have I Been Pwned.
On top of setting a password, you will have to enable OTP auth at this stage. This is mandatory when using your own password.
This might sound like a headache... sure, however your and my safety is more important to me.
Of course, nothing ever is totally safe. However we can go some way to make it harder to gain unauthorised access to your account and servers.
This hasn't built yet, however I am also planning to add OTP auth for magic links for extra security. This isn't mandatory at the start, but can be set later on in settings.
On top of this, I am also researching the use of WebAuthn. Which basically allows you to use security keys and other methods for authentication where supported.
So now that we have the lowdown on options, here is a screenshot of the password preference screen:
I highlight the magic links, as they're convenient. Gently nudging you in that direction. Depending on what you select, you'll go to the next steps. Which are yet to come.
One note on registration, once you entered your email and advanced to the next step you're already logged into the account automatically. So if you decide to leave and come back later, you will be redirect to the correct registration process. So I'll double check which step you're at and redirect as needed.
That's as far as I got over the weekend. It's been fun working on it so far. It's also fun to work on the frontend and backend at the same time, which is a nice flow. With Simple Schedule I built out the frontend first and then the backend. This worked fine and gave me a clickable prototype... however it also introduced wasted work for features that didn't make it.
For this week I am planning on finishing the registration process for both magic links and password setting. I'll probably also then work on the login part.
That's it for now.
Spent a few hours working on Picard.sh today. Felt good. Going to do a small write up tomorrow about it.
Just working on database design. Nice to do something a little different.
Now to come up with, and create, the User table… pen and paper are not doing the trick so far. Gonna head for the shower and drink some herbal tea instead.
Here is my super simple take on the registration page for Picard. It has a bit of extra text when you’re coming in from an invite. I want to keep it simple without headaches. Password can be created later, if so desired.
Added the ability to send a registration invite for Picard, which you’ll need in order to register before the public launch. Seems to work nicely. Also have an ENV variable to toggle if it’s open for public.
When I push the button in the admin it will create a token and trigger an email with a special link. Trying to register without the correct details will boot you back to the homepage:
With that, I’m starting the registration screen:
I kinda dig the stars, so I’ll leave them for now. Not sure how to tackle the logged in area yet from a design point… we’ll see.
I worked on a super simple admin area for Picard last night. Just so I can handle any requests coming in, like deletion or Marketing preference changes. Also added the ability to re-send all pending/non-confirmed invites on a one time basis.
The screenshot is my local instance and you can see a few things, for example if they confirmed their email. When they pre-register it sends out an automatic email so they can verify it. If they didn’t I have the ability to send “All pending invites” again, however I can only do it once per email - I want to avoid spam - and also added some extra text to the email template stating exactly that. I could automate this on a weekly basis perhaps, but this will do for now and will come in handy when I’m ready to open it up. Other options include marketing preference toggle - easy enough - and the delete button.
The data in the database is encrypted so I had to find a way to do something quickly, as the database won’t tell me much except encrypted garbage.
Anyway, this was a bit of fun for me and probably not really necessary… However I can build on top of this and add new features as I go.
Next up for today I will work on Login and Register. Will post an update when I can.
Every month I spend more money just to manage my servers and apps than actually running them. Having multiple providers to manage different projects and frameworks isn't great. I want a solution that is fair, doesn't have limits - like the amount of servers - and ticks a few essential boxes with flexibility.
If you’re a freelancer or a small time dev, running your own servers, and using multiple frameworks you know that you usually have to jump through hoops to get everything up and running. Not to mention using different providers for your specific use case or framework.
This is my exact problem right now, in fact it has been like this for years! I run PHP projects (namely CMS’s), Ruby based projects (Rails) and an army of static websites from basic HTML to one-page JS apps built with Jekyll, React and others.
At best you can combine several providers to get the job done for you. I’m a visual person and also like things to be easy, so having a web app that can manage my servers is an absolute life saver. As a freelancer I don’t want to mess around with server configuration.
However, here is the rub… these services usually cost a hefty amount each month, they oppose limits to how many servers you can run on a price plan and, in most cases, limit what you can run on the servers without having to actually SSH into your server.
Don’t get me wrong, I think it’s good that a tool exists for a specific toolset and I’m very grateful that they exist today and make it easier to run my day to day operations with ease.
I’m looking at combining the best of all worlds in one service, to satisfy my own needs right now. Not only that, I also want to learn much more about server set up. I already have a good understanding of it all, however I really want to dig into the bare metal of it all to truly appreciate it. Not only that, I also want to learn how to take this knowledge and combine it with a web app.
Life is busy as it is, so if I can work on something that replaces two or even three providers with one then that’s good in my book. Not only that, technically, I’ll be reducing my own monthly outgoings for managing the servers to zero. I totally understand that I need to run the infrastructure for this, but I could in theory spin up 10 basic Linode boxes ($5/month) and still come in way under what I spend now on other server management services.
So this is project Picard - a server provisioning service for Ruby on Rails, Laravel and static based projects, with zero downtime deployments. Which, of course, will include your usual mix of common PHP CMS platforms like Craft CMS or Wordpress.
Like with my other challenges, I’ll be regularly blogging about the build and will also be opening up on what exact features I have in mind as time goes. I don’t want to spill the beans straight away.
I’m thinking of also doing a small micro-cast as I go for a few things. It’s a bit different for me, but I’d love to try at least. Get my voice out there. Always weird to see someone write but not know what they sound like.
So, getting to it… I have created a pre-registration page where you can sign up to be notified when it’s ready to launch. I took great care to make sure your data is encrypted. I can’t be PCI compliant, as I’m only one person, but I’ll try and stick to this as close as possible. Everything will be encrypted and I take security and privacy seriously. During sign up, you can also let me know if you’re interested in general updates that I will email out. You don’t have to if you don’t want to. I’m building my very own mailer for this, so no third party reliance here.
When I’m ready, I’ll be inviting a few people to help me test (if you’re interested of course).
I’ll share the link at the end of the post, however first you get to see a nice screenshot of the holding page:
OMG… THIS LOOKS LIKE A KID MADE IT! So what? I think most web apps and service try to be way too serious these days! I want to bring back a bit of fun and character. Just like most cars today… they look totally mean like they’re going to beat you up. So, I want to have a bit of fun and inject a bit of life and colour into it… whilst being extremely useful at the same time.
Good question. It’s cool stuff, but there are still many people that just want to run a simple server and get their stuff running the tried and tested way. I totally recognise this need for serverless, but deep down I think it’s another way to put off new-comers into the world of development. So here I am trying to find a balance of usefulness and ease of use without breaking your and my head. If I ever go that route I will probably explore that.
This project has just started and will be a rough 3 month project for me. Well, I’m giving myself 3 months for a basic, but feature rich, web application.
I already have pre-registration finished and am currently working on implementing a backend to help me manage mailing and other tools like inviting a batch of people for testing. It’s not at the top of my priority list, but it will play a good role later on in the project.
Next thing after that I’ll work on registration and login and promoting pre-registered users to a full account.
I always like to work from outside to in. So I work on it step by step like a normal person would use it.
Instead of writing the frontend first in a separate app, I’m actually going to be building the frontend straight into the app, so I don’t have to copy anything across at a later stage… because things always change as you write the actual code. This should make it a bit faster for me.
Of course, as I said, I’ll be blogging about pretty much everything again - so that’s gonna be fun for me.
Here is the website you can pre-register on: picard.sh.
If there are any problems, just let me know straight away. You’ll have to confirm your email in order to receive an invite email once it’s ready and the occasional update. If you don’t then I won’t email anything, just to avoid fake sign ups (it happens people!).
Anyway, I’m SUPER happy I took time to write this and announce it. I’ll be announcing specific features and pricing as we get closer, but feel free to send suggestions if you think this will be of use to you (S3 backups out the box, Python and node projects… just to give you some totally random ideas here).
