Why not run migrations from a local computer in production?

[romik]

Everyone talks about running migrations necessarily on a server. But why not to run migrations and seeds from a local computer in the production mode? Are there downsides? A database is available via internet.

Why has no one told me that during many years?

Why strugle with bin/my_app eval "MyApp.Releases.migrate" and the like ?

[jukvalim]

Downsides that come to mind:

• Making the database available via public internet is a security risk.
• In a well set-up project, you generally want the migrations to run as a part of a continuous delivery pipeline, automatically rather than manually. Running migrations on local developer machine is not compatible with this.

I guess the downsides are big enough for people not to go around recommending it.

[shanesveller]

@jukvalim

Making the database available via public internet is a security risk.

This is my first concern with the suggestion, and my second concern is that it means developers must necessarily have highly-privileged SQL credentials available to them locally, that are able to execute DDL statements. Both of these are not acceptable practices IMO, and together present a very real risk of data breach or destruction if that developer’s machine were stolen, they get terminated and choose to retaliate, etc.

Interpersonal trust is not a security model.

[romik]

@jukvalim

Making the database available via public internet is a security risk.

Something is available to public always, and needs to be. At least your server is, via ssh connection. How is a database with a long password less secure?

[romik]

@shanesveller

it means developers must necessarily have highly-privileged SQL credentials available to them locally, that are able to execute DDL statements. Both of these are not acceptable practices IMO,

SQL credentials are available to me as a developer locally anyways because that’s where I specify them, and then they upload to a server during a deploy. They aren’t in git.

[mindriot]

@romik

SQL credentials are available to me as a developer locally anyways because that’s where I specify them, and then they upload to a server during a deploy. They aren’t in git.

Ideally the deployment pipeline would use a credential store of some kind and pull them from there.

Another reason why having the deployment pipeline handle migrations is it prevents issues where local developer machines could have a variance in setup that might impact the production environment.

[jukvalim]

@romik

Something is available to public always, and needs to be. At least your server is, via ssh connection. How is a database with a long password less secure?

It’s not less secure than SSH with long password. Although SSH can be made more secure by only allowing public key authentication, or not allowing access from public internet at all. Access could be limited to certain IPs, or only allowed from inside a VPN.

The idea is to reduce the attack surface area. The more services there are that are accessible to public internet, the higher the chance that something gets misconfigured or a secret leaks and an attacker gets through.

Don’t get me wrong, I’m not saying that this technique can’t be used anywhere. Projects are different. Something that would be unacceptable in a company dealing with confidential data might be a reasonable, fast way to get things done in a personal project.

[wanton7]

It’s very bad idea to make anything public from production servers that don’t need to be public like others have said. But second because there might be security hole in your databases login. Meaning attacker could attack it and get access. Databases are not in most cases designed to be put visible to internet. They haven’t been hardenet against attacks like web servers usually have. Losing your data to an attack can be business ending situation so take it seriously.