Handle specifying domain name in settings page

[bharatagarwal]

Here's what I was thinking:

Maybe, we allow users to deploy an app to mothershipapp.io by default but will only be deployed for 1 hour.

Otherwise, the user can specify their own domain, we give them the steps to do it, and then generate the necessary services for it.

[icevans]

I like the idea that the user can specify a custom URL if they want one, but I don't see any reason to delete an app that just uses the URL we generate

[jkulton]

@bharatagarwal do you mean that we specifically own mothershipapp.io and allow users of our open source project to deploy apps there if they don't have a custom domain ready themselves?

Very interesting idea.

[icevans]

Ahhh, I get it. That could be cool, although it would mean we'd be paying the hosting bill for their app.

[bharatagarwal]

That's why I was saying just keeping it live for an hour or so.

[icevans]

Changing the domain wouldn't move it off of our cluster though... for that they'd have to deploy our PaaS on their own server and then redeploy their app there, right?

So we could have our own custom deployed version that tells people you can try it out for a demo, but your app will be gone after an hour. For permanent deploys, deploy the PaaS yourself.

[icevans]

Is that last bit what you mean by "Otherwise, the user can specify their own domain, we give them the steps to do it, and then generate the necessary services for it"?

I was picturing that deploying our PaaS is done via a CLI, is the idea here that you could do it from the web?

[bharatagarwal]

I think you got it in the comment about permanent deploys.

I guess where I was coming from was, that if you don't have a custom domain available to you, there. should be a way to deploy apps, which I was thinking for demonstration purposes we could deploy from mothershipapp.io.

I don't remember what I meant by the sentence you've highlighted :/

[jkulton]

I was thinking about the settings page feature where users can change their domain and realized a couple of things:

1. If we offer this feature, we'll need to ask them to update their DNS resource records (like they do the first time they are enabling a domain)
2. We currently hardcode the URL for apps on the apps table. (Even if we don't add this feature, we should probably make app URLs a method on the app model, rather than a DB-stored value). This way if the mothership domain does change, we don't need to update rows in the app table. Plus, app urls are a value we can derive with existing data.

i.e.

App.prototype.url = () => {
  return `${this.title}.${mothershipDomain}`;
}

We'd need to find a way to get the mothershipDomain value so we don't need to query the config table every time we need to display an app url.

[icevans]

Yea, you're right about that. I think this one won't make it into v1.

It would be nice to give them the ability to change the url for a particular app, though (assuming they'd set up a DNS record for a new URL to point at the manager IP). In that case, we probably do want the URL in the database, because you can't necessarily compute it from anything else.

This feature isn't critical if the PaaS is for internal apps, but consultancies using it to deploy small client apps would want to set a real domain name for deployed apps.