We will shortly be moving existing customers to Amazon Web Services (AWS) servers, and new customers will be hosted on AWS too.  Some questions you may have:

Why are you moving?

AWS offers a more scalable and resilient setup than we can deliver on our existing host.  Because AWS provide this platform at such a large scale they are able to invest in technologies that take care of some of the hard server problems, so that we don’t need to.  Hosting on AWS should improve the resilience and performance of Lamplight – it’ll be quicker and less likely to experience server problems.

Where will our data be?

In London (UK!).  We are using the AWS London region exclusively.

What will it cost us?

Nothing.  The hosting charges will not change as a result of the move, and there is no charge to transfer you to the new servers.

Is it secure?

Yes, and in some ways more secure than at present.  As currently, databases and files are encrypted at rest and in transit.  Servers exist in private networks that are inaccessible from the internet.  Security features already present will continue.  Amazon do not access your data.

Snapshot backups of databases are automatically taken nightly, encrypted, and multiple copies stored on Amazon S3 storage.  These can be restored quickly if needed.  File storage also uses S3 and multiple copies are automatically created and stored to ensure high availability.

What will change?

Two things.

  1. The web address will change to https://lamplight.online, and your login at https://www.lamplight3.info will no longer work.  Your existing username and password will continue to work on the new server.
  2. You will not be able to send emails out directly using the Lamplight servers.  The only emails we can send are passwords for operators.  For other email you will need to either
    1. Link Lamplight to your own email server
    2. Use Mailchimp

This Setting up Email Accounts document will explain what settings you need, and how to enter them into Lamplight.

If you use the publishing module you will need to update your implementation when the changeover happens, to use https://lamplight.online instead of https://www.lamplight3.info.

Why to I need to set up email to send sms?

To send sms messages we link up with a company called 24x, who send the text messages.  To get them to 24x, your sms messages are sent by email, and are then transformed into text messages by 24x.  So to send sms messages from the AWS servers, you’ll need working email.

By way of analogy, imagine you want to send a postcard to a lighthouse keeper.  Now the postman won’t row a boat out to the lighthouse to deliver it directly.  So instead, you write your postcard, put it in an envelope, and add a little note asking the lighthouse keeper’s wife (who lives in the cottage on the shore) to pass it on to the lighthouse keeper.  She gets the letter, reads the note, and pops the postcard in the lunchbox and sends it over to the lighthouse keeper.

So the postcard is our text message; the envelope is the email; and the lighthouse keeper’s wife is 24x.

(Update on sending sms – 9/11/2017)

We’ve made some changes to the way Lamplight sends text messages and you no longer need email set up to send sms messages.  Messages are now routed to 24x directly.

When will the change happen?

We can schedule that to suit you.  There will be a short period of downtime (ranging from a few minutes to a couple of hours for customers with large volumes of files and data).  System administrators will soon see a screen when they log in asking them to accept the change to the hosting agreement (as our previous host, Elastichosts, are referenced in it), and asking when they would like to schedule the move.

How long will it take to move our data?

The process is fully automated and typically takes a few minutes.  Customers with large volumes of data will take a little longer, but it won’t be more than a couple of hours.

Do I have to sign anything?

No.  You can confirm your acceptance of the changeover using the tickboxes that admins will see when they log in to their current system.  You will be emailed a Hosting Agreement Amendment for your records.

Why is my question not answered here?

Because we didn’t anticipate it! Please Contact Us and we’ll update this page with other Q&As.

We’ve recently launched our integration with Mailchimp, allowing you to synchronise your contacts with Mailchimp, send campaigns through Mailchimp, and have them appear back in Lamplight, linked to the recipients.  You get the email templates, deliverability, and reporting functionality of Mailchimp, integrated with the ‘overall picture’ view you get in Lamplight.  It’s being used by a number of our customers already.

There’s a downside.  You’re trusting Mailchimp with the names and email addresses of your contacts.  That’s a judgement you need to make; for many of our customers that’s fine; for others it may not be.  Of course it’s the same judgement you make with us.

We occasionally get asked about other integrations – can we do reports on Google Maps?  Can we publish work records to Facebook events?

This is obviously attractive.  Why build a geographic reporting system from scratch when Google have done it so well?  Why not save me some double typing and let Lamplight post things to Facebook?



There are different kinds of integration.  Essentially these can be divided between server-to-server integrations and client-side integrations.  With Mailchimp, our servers talk directly to Mailchimp’s servers.  We can control what we tell Mailchimp, and what messages we accept from them.

But client-side integrations are different.  Something like a Facebook ‘like’ button, or a Google Map within Lamplight, effectively give access permission to Facebook or Google or whoever to Lamplight as if they were you.  Those maps or buttons contain javascript programs that ‘like’ or ‘map’ – but in principle they could also scrape all your data, send it back to base, and then delete it.  And we could have no control over that, because as far as Lamplight’s concerned, it’d be you doing it.

We don’t actually think those companies would do that.  But in principle they could.  And that’s a good enough reason for us not to.


A related issue is knowing where your data is.  With Mailchimp, it’s very explicit that you’re sending names and email address to them.  You have to opt-in and set it all up, and it’s obvious that’s what’s happening.

But there may be more subtle data sharing going on with client-side integrations.  A geographic reporting feature using Google Maps would require that you share the data you’re reporting (client addresses and self-confidence ratings?) with Google – and that may not be obvious to you.

Even more subtle are new features within web browsers.  One really neat one that’s arrived relatively recently is voice recognition – you’ll see the little microphone in Google’s search bar that lets you say your search terms.  When this came out we thought it’d be awesome to be able to dictate your work records instead of all that typing.  But it turns out that the voice recognition happens remotely – the audio is sent to Google servers where it’s converted into text and sent back.  So adding this to Lamplight would have meant that any data you spoke into Lamplight would also be being shared with Google.  Again, we don’t actually think they would misuse it, but we don’t trust them with your data to be adding it to Lamplight, however neat it would be.

To conclude

We think the best approach to security issues is excessive paranoia.  Server-to-server integrations allow us complete control over what is shared with external services.  And that sharing is explicit, and opted-in to by you: if you don’t turn it on and set it up, nothing happens.

But we are completely powerless over client-side integrations: in principle it’s equivalent to sending your username and password to that external service.  And the data sharing that necessarily happens with client-side integrations may be subtle.